The long stable uptime of linux is a terrible thing
Why, you ask?
Because when I have to open up a case to do something, and I finally get it working, I am immediately loathe to turn it off to tuck everything back in the case :P
That, and I've been sorting through all my old junk to put stuff together in the form of working computers, and I'm tired of computer work
What's going on?
* asdfqwega has just been up late, doing CAD work, python script coding, and enjoying a heather ale
it's nice to sleep late on a saturday morning...
Working on this laser has turned me into a photophobe :P
paul, got some time?
about that diff...
I made it yesterday... the main difference is the ./configure file
between the autoconf tree and the trunk
configure, I would have expected...
What about the sources ?
* alex_joni forgot a make clean first, and there are still some autoconf temporary stuff in there, that's gotta go
let me do 2 clean checkouts
the diff is 400kB (was 1.6MB)
modified files: CVS-stuff (normal)
Make.rules (another rule added by zwisk: TARGET_DIR: install -d first)
Makefile (a lot about make install)
configs/TkEmc added (missing in trunk)
configs/emc.conf.in added (not good)
configs/emc.ini modified (zwisk added $EMC2CONFIGDIR which gets replaced during make install, also not good for the trunk)
configs/hal.conf.in added (ditto)
configs/rtapi.conf.in added (ditto)
./configure modified (normal)
docs/recomended_reading.txt (was removed from trunk)
src/emc/rs274ngc/rs274ngc_errors.cc modified (by paul_c ;)
src/hal/Makefile modified (replaced $(EMC2_HOME) with ../../ )
src/hal/hal.h modified (a comment was added)
src/hal/hal_priv.h modified (could be from the fixes jmk did on trunk)
src/hal/utils/halcmd.c (added #include "../../config.h", also missing del_sig function I added to trunk)
src/libnml/Makefile modified (replaced the separate list for the subdirs with a for)
src/po/stuff was added to trunk
tcl/tkemc.tcl modified (I replaced tcl/bin with $TCLBINDIR where it was not replaced already)
that's about it... ;)
got a diff here...
I tried to summarize what is modified in each file
emc2/debian is a new sub-tree...
* alex_joni noticed some files in the autoconf_install tree are not needed
yeah I know... that's why I didn't say anything about debian/stuff...
that could get merged to the trunk
but a lot of stuff shouldn't
Just stripping out text files & configure from the diff...
3,145 lines now.
* alex_joni has got to go eat lunch...
i'll be back later.. ok?
I'll leave it on.. read when I get back...
* robin_sz waves from Geneva
you're back over there then ?
I am indeed
back in a bit - Coffee...
I just never can seem to win
paul_c, alex_joni: why is configure, a generated file, included in CVS?
So that peope who don't have the right autotools versions can do a ./configure && make ?
most peoples' cvs trees seem not to include it .. it is frustrating sometimes, not having the right version, I'll agree.
It is a bone of contention with many projects..
my fedora system has: autoconf (2.59) autoconf213, automake (1.8.5) automake14, automake15, automake16, automake17
that seems a bit extreme but oh well
one of the boxes here has a real old autoconf...
Is alex_joni back from lunch yet ?
* alex_joni just got back
Looking over the diff of the core changes...
* alex_joni is a little bit confused ... about the diff stuff
the diff is only for reviewing purposes?
the rs274ngc changes should have been made in the main trunk - These are for i18n support...
submitted to the wrong tree?
The diff enables me to see what has changed & where..
Two areas of the changes trouble me....
what should _I_ do?
maybe I can help...
emc.run - awk, grep, & friends should not be variables in my opinion.
It looks ugly, and opens up a huge security hole.
If grep & Co are missing from the system, then te run should fail, and it isn't our problem to fix a buggered install.
I see your point
but if those are missing ./configure fails
so make fails
so emc.run has no point...
assuming you build and run on the same box
A malcontent could alter the config to point to a screwball script...
ok... then you suggest removing the $GREP & co. from emc.run ?
Replacing the variables with the proper names.
so no more $GREP but grep
that can be done...
anyways... I'd suggest the following
why not merge only ./configure, configure.in and Makefile.inc.in
and work on the rest till it's ok (make install and what else needs to be done)
* paul_c is looking at scripts/realtime....
don't like $EMC_RTAPICONF - What is it, and where is it sourced from ??
paul: take a look at autoconf_install_0_1
it's way different there
03alex_joni 07autoconf_install_0_1 * 10emc2/configs/ (emc.conf.in hal.conf.in rtapi.conf.in): removed some unused files. those are used only in the auto_configure_0_1 tree.
* alex_joni is back in 10 mins
diff between emc2 trunk and auto_install...
* alex_joni is back...
seems I cought a virus :)
I see the auto-install has an emc.run.in
so that paths get put into emc.run during ./configure
sorry.. I had to leave shortly... but I'm here to stay now..
I just realized I have 500 MB in the E-Mail folders :(
paul_c: still around?
should I sing a lulaby?
you can blow a wallaby for all I care ;)
keep it down robin ;)
how's your laser robin?
or was that <bang> <crash> coming from the laser?
im not near it at the moment
oh... I see,
in geneve ;0
what'cha doing there?
my other job ...
the stamp auction
I thought some hitmen convention...
just finishing off the last few lots now ...
I'm wondering if paul is actually sleeping ,)
could be ...
im thinking of CNC'ing a pressbrake ...
metal bending press ...
I think I've seen a few (CNC ones)
paul_c: still sleeping?
* alex_joni is going home... I'll be back online in an hour or so...
* alex_joni is back
how's it going?
haven't writen some code up to now
i thought i have much more time this week
have you merged your work to emc ?
what work do you mean?
the stuff on autoconf?
still talking with paul_c on how it should get done
but paul is away right now, I think
Martin, still around?
* alex_joni is eating... so no urge for work here
don't worry.. i'll bug you some other time *g*
well.. I talked to jmk last sunday
and he proposed that the ./configure should get merged
I said I want to ask you first...
still asking ;)
as fas as I have been reading (red-book and other coloured books)
either the whole branch can be merged (which I don't think is proper to do right now)
or only some files should get merged (I'd propose: configure.in, ./configure and Makefile.inc.in)
with those emc2-trunk would still be with all the current functionality
Is the confugure.in as clean, simple, and well documented ?
i think so...
Sounds like you are just about ready to merge some of the files then.
cradek: did you ever try full-step driving your mill? I think the firmware for that board was designed to change to that mode with a #define. Did it result in increased speed? You can afford to give up the resolution, I think.
Or even "Yo"
How's the disk project?
Sent you an email on that the other night.
Someone cut the fiber while digging down by the wis border.
I believe I lost a bunch.
paul: cvs update -j auto_configure_0_1 configure.in ?
in the emc2 trunk dir ?
Does it merge just the one file ?
that command was intended for one file
same command (if it's ok for the other 2 files: Makefile.inc.in and ./configure)
Do you want to do the rs274ngc dir as well...
so the command sounds right...
give it a spin
hard at work in merging both ./configure ;)
I'll do a autoconf on configure.in to make sure it's ok
hope I'm not doing anything wrong ...
03alex_joni * 10emc2/ (4 files in 2 dirs):
Merged the autoconf created ./configure; ./configure gets created by
configure.in by running autoconf. autoconf must be run only once, the created
./configure can now be run on different targets to test those systems. The final
user does not need to have autoconf or other autotools installed to use this.
This was developed on a branch (auto_configure_0_1), and moved now to the trunk.
paul_c: Nothing yet.
Got a few inches of wet snow. The grandkid is making a yardfull of snowmen.
hmmm.. something's weird...
not weird.. I take that back ;)
I thought emc2 is broken.. but it's not
realtime wouldn't start...
seems that a /etc/rtapi.conf was found (with stupid values in it...), left over from some tests I did a while ago
but emc2 seems to run nicely here
maybe somebody else could try it out too? it now contains the autoconf stuff
there shouldn't be any "values" in rtapi.conf
there is $EMC2_HOME
and that was set to /usr/local
so it tried to run 'cd $EMC2_HOME/scripts' which obviously failed
but those were faulty tests on this machine.. so nothing normaly should be encountered
20-40 kB/sec for a ssh-forward of TkEmc and TkEmc Backplot (working nicely on a wifi connection)
paul: do you know apt4rpm ?
is it a pop group ?
it's a tool to make apt accessible for rpm based distros
now that I'm reading the info it makes a apt-repository out of a rpm one
so that tools like synaptic can be used.
it's basicly for rpm-based distros (SuSE, RedHat, etc...) to be able to have the flexibility of apt
I wonder if deb packages can be installed ... gotta read more about it
Not unless you uae alien
but the scope to break a system is vast...
I guess so...
having the root password... just qualifies for anything
"The graphical frontend, Synaptic, for apt is now available for SuSE 8.2 and up."
And any other RPM based disro.
yeah.. this was taken for a SuSE specific APT4RPM site
ok... Chips is done
guess I'll crash ;)
do you think it's ok with the EMC2 trunk?
We'll find out when the farm kicks in.
if... it's not hung
* Imperator_ has compiled the new EMC2 code and it works fine on that Redhat 7.2 based BDI
* Imperator_ thinks that Alex has made a good job
it's no new EMC2 code
only ./configure is new
it runs fine
and it's not only me ... it was also paul's contribution
a lot of tests are from the old ./configure
glad to hear that
thats a good thing
thanks to Alex and Paul
did anything change on the makefiles in all that directorys ???
tried to keep the step as small as possible ;)
at the end all the makefiles are changing to makefile.in or something ?
makefiles could be changed to makefile.ac
and using automake they could be converted to Makefile's ... but
ac=auto config ?
I don't think that would bring much good
that leeds then to a Makefile.in created by automake
the Makefile.in would be modified by ./configure to a final Makefile
but I don't think we should go there...
in which case do you/we need that ??
hmm.. it is usefull.. but I'd take that in consideration for a new project
not for a grown one...
it usually uses one single Makefile... not very easy to administer
Imperator_: still around?
how's the mot stuff looking?
I think not that complicated
nice... I wanna take a look at it too sometime... but now I'm too tired ;)
maybe i will do some other improvements before implementing the gantry stuff
today is electrion day here
the stuff about configuring the motion parameters
there is a big command on top of command.c about that