good discussions here - want to save them ok.. let's drift back alex_joni: you were saying, "one .ini file" ... yup.. so we have one ini file which includes more .hal files (points to them) reading from emc.ini: HALFILE1 = core_stepper.hal HALFILE2 = standard_pinout.hal hmm... we get into all sorts of interesting semantics quikcly. modularity is both a strength and a weakness of hal indeed. if you have steppers with stepgen, you set scaling by "setp stepgen.0.position-scale = 1234" if you have steppers with freqgen, you set scaling with a different setp command if you have servos, you use yet another command yup... on freqgen you have a velocity scale can the hal 'pin' model be used to connect 'servo 0' to configuration parameter 'AXIS0' somehow? and you must have a different module to feedback.. right? that's good, if you build your machine from the bottom up - get the motors working, then add emc above them to do the overall controll I really want a config utility. :) because in the bottom up version, you can't depend on emc to set the scaling zwisk: define configuration parameter 'AXIS0' alex: AXIS_0 from emc.ini zwisk: the best thing would be a halgui I see... not really perhaps more than just hal, though, right? AXIS_0 contains a lot of things right most of them to be sent to hal (using setp) yes, which is the point. "stepgen.0" needs to be able to axis the things in "AXIS_0" (if mapped) and take what it needs. right not link pin the problem is that I want to be able to set up and test an axis using hal alone I think that's a fine goal, john. Once it's tested, though, should not the config live in emc.ini somehow? I like that too I did it like that in .hal because it's emc-independent so, now we have emc.ini and lots of *.hal's ... well... we could have one .hal per machine.. but that would clutter things up zwisk: yes, once it's tested, you should just be able to use it without thinking about hal again when splitting the .hal into more.. you could have some .hal's that you never change So how does hal get mapped to emc? What causes stepgen.0 to be considered AXIS_0 inside emc? like (one basic for stepper operation, e.g. core_stepper.hal) that's the logic behind "core-stepper.hal" and "standard-pinout.hal" you have a axis.0. inside .hal there is a xylotex-pinout.hal that flips the step and dir pins, for xylotex cards e.g. Xpos-cmd (is a signal that maps axis.0.motor-pos-cmd with stepgen.0.position-cmd) zwisk: I didn't think it thru completely... but in general, *.ini should config the core of emc same with Xpos-fb so, I think that means that all AXIS_[0123] should get pulled from emc.ini ? and *.hal connects the core to the outlying modules like stepgen does hal take care of PID tuning somehow then? my thoughts on that were that yes, hal would handle tuning IOW, tuning parameters would be hal parameters associated with the PID hal module if you want to run an axis (joint) independent of emc.. you should have tuning btw. exactly it's easier to tune with some scope feedback you might tune an axis using siggen, scope, and the hal modules only so, what's the 'top' level that hal exports then? step/dir? Position? maybe in the future (near or far) some utility which paints the motor response... position-cmd and position-fb zwisk: do you do electronics? ok. So emc says go to this position, and hal does that? yep, I do electronics. as far as I see it in core_stepper.hal pretty much ok - so do I, and that's what drives my mental model of HAL hal takes care how to get there... How are multiple axis coordinated? how to drive (be it steppers, servo, AC, etc.) HAL is a block diagram - it shows what "blocks" you have, and how they are connected the emc core does multi-axis coordination the whole thing get's fed into the NGC the "emc core" block has position command outputs for each axis (and position feedback inputs for each axis) Ok... but... if it's giving location data to hal, how does hal coordinate multiple locations on mulitple axis? Does EMC break it into small 1 dimensional moves for hal? you connect those outputs to whatever other HAL blocks are appropriate for the motor zwisk: yes for small 1 dimensional moves * jmkasunich can't talk without draqwing pictures emc spits out position commands for all axis simultaneously ok.. I'm good. I think I've got it now. each command is sent to individual step generators, or PID blocks, or whatever that axis needs Ok, so from a bottom up architecture, Hal is really cool. The user, howevever, needs somehow to feel like they're working in a unified system. That may just be tools that wrap around emc and hal to make it look like one system. zwisk: you've hit the nail on the head I like the bottom up, and once you grok the concepts it's very powerfull and flexible that could be halgui? So, am I right ins aying that (almost) all of the AXIS_* comes out of emc.ini ? but if you want to work top down, it isn't very friendly zwisk - the problem is that some info is needed by both the low level and the high level I think realtime configuration in the rework is even more important given this realization, because top-down folks will need tools that rework the things at the bottom, and rebuild up for them. could be halgui. I am thinking of something LabView-like But it should encompass more than hal. It needs to tie in the things in emc.ini that need to be 'synced' with hal. LIke that axis 1 in lienar, and 2 is angular, etc... or axis1 max speed yes... and axis scale axis scale right now is a hal thing. Axis max speed is ... an emc thing? the hal needs to know (stepgen max freq, for instance) and emc core also needs to know (for trajectory planning) right now, hal and emc get max vel from different places, and the user is responsible for keeping them matched that that's bad what if the emc.ini file contains HAL blocks? that could work... putting a hal block within AXIS_1 that is responsible for setting up axis_1 might make sense. I don't understand need some halcmd adjustments in order to disregard stuff it doesn't know jmk: in emc.ini ... at axis 0 you could have some hal stuff duh "hal block" = "sequence of halcmd commands"? yup if [AXIS_1] in emc.ini countains a [HAL] block taht contains all the hal cmds (like the .hal file) to create all the hal modules... yeah... hal cmds. or at least some AXIS_HAL = axis0.hal that would help - keeps related stuff together or something like that (although I like the first version better) the ini format doesn't allow nested blocks * paul_c steps into the middle of a converstation... go right ahead You guys talking about nested [SECTIONS] ? not really, we just wandered into that topic I guess... though I'm not sure that's a requirement. 'cos you can't nest [FOO] inside [BAR] instead of having the hal data in it's own section, but the hal configs for each axis in that [AXIS] section exactly - that's what I just pointed out Maybe it's just HAL_AXIS_1 then ... The ini file parser treats each [ as the end of section marker would require a significant rewrite of the ini parser right after AXIS_1 you could have HAL_AXIS_1 no need of rewriting if we really wanted to, we could modify the parser so it treats [/FOO] as the end of section [FOO] jmk: loadrt loads the module? yes XML like? It's almost tempting to see if there is a config library out there we could use. There is a couple Why reinvent the parser when others do it and maintain it. what we're talking about is only a partial fix tho * asdfqwega [lurking] Not wanting to derail this train of thought... * alex_joni is having a closer look why halcmd loadrt is not loading the proper modules we would still have "setp stepgen.0.max_freq" and "[AXIS_0] max_speed", and the user would have to keep them in sync all we're discussing is how to keep them close together to make it easier that seems like a bit of a shame. zwisk: zwisk: that's the good and bad of hal hmmm.. short question here being able to set stepgen.0.max_freq when testing the axis is goot good what's the ration between stepgen.max_freq and max_speed ? but having to separately tell the traj planner about it is bad yep, the good and bad. but maybe we can make emc help out by doing more of the configuration of hal somehow? s/ration/ratio/ alex_joni: the ratio isn't neccessarily simple - one might be in Hz, the other in mm/sec hey... what if we extend HAL to allow emc to ask hal, generically, for those parameters? exactly... (max speed _is_ in length/sec) how could the user be able to tweak that? but emc has to know which ones to ask for EMC should ask the underlying HAL system what it's fastest rate is. and I mean USER a stepper axis: stepgen.0.max_freq * stepgen.0.position_scale (I think) for a servo axis, it will be different EMC should just ask for what it knows. HAL, which knows what type it is (and has the position_scale) should answer properly. yup.. that's very wise spoken but HAL doesnt' know what doesn't hal know? * jmkasunich needs a pencil again there is no "HAL" as an entity hal after loading all the appropiate .hal files hal is just a shell that glues together blocks as the user (or configurator) instructs it Hmm... maybe there should be? A hal "machine" abstraction, into which all of these components load? that's emc.. slightly below that :0 actually not below it at all the emc motion module is just another block Something that knows the concept of the axis and can feed back up the type, maximum rates, max speed, max acceleration, etc... as is the g-code interpreter, etc today, emc.run is what loads the blocks g-code interpreter is a hal module? no - they aren't hal blocks, but they are blocks in the larger sense of being distinct programs that are loaded by emc.run hmm... well it can't be both ways, right? Either hal is smart enough to load the blocks, and dictates everything, or the blocks are set up in .hal files and emc asks what gets set up for it's properties. before, there were only a few blocks - hal has made many more, which complicates things sorry... that should be "either emc is smart enough". jmk: is there any place I should check why halcmd loadrt is failing? besides trying it manually what error message does it give? well it can't find the pins I don't get an error message regarding the module loading pins? loadrt doesn't care about pins are you running a single loadrt command, or a hal file with loadrt and other commands as well I am running emc.run :D doh... sorry guys, I gotta go. I'll try to catch up on the conversation tomorrow... ok zwisk bye.. zwisk later! this conversation was really needed... (however it's not over yet ) definitely I do get: HAL: ERROR: Can't find module 'stepgen' in guess it has no idea where the modules are right * jmkasunich opens halcmd.c which branch are you using ? autoconf try the main trunk I' the autoconf may be broken last time it worked... should work now too it sure is.. I am trying to see where in the autoconf branch, halcmd.c, line 903 add a printf there to see what file it's trying to load probably missing the path hmmmm just a mo. what is the main directory called for your cvs checkout? emc2? or something else, like emc2auto? it's /usr/local/nist/emc2-autoconfigure/emc2 and the halcmd executable is in /usr/local/nist/emc2-autoconfigure/emc2/bin? hmm.. not really after make test well that's why stuff get's copied into emc2/test/usr/local/bin the bin stuff anyways loadrt looks up the path to it's own executable, then goes up one step, and looks for /rtlib the modules go to emc2/test/lib/modules/2.4.21-adeos/rtai/ that _only_ works for run in place - I planned all along to do something better, but you guys are way ahead of my in the main branch yes... but in the autoconf branch there are some things modifies to allow it to work... just not 100% ok yet there's an ENV variable HAL_RTMOD_DIR that get's checked (around line 809) right - IF that is set correctly, then it should work otherwise you're screwed, cause the rest of that cruft breaks miserably unless the directory structure is just right yup.. I see some /proc/self/exe support in here .. ;) so if you set the env variable manually, does it work? JS-was around let me try nope - that was me really? he did add some comments thou.. yes * jmkasunich looks to see what he added (I think it's lines 825-830) then next two blocks (the one using proc/self/exe, and the one that uses the current working dir) were mine strange is: the module dir gets found but it's void while we are on the subject of adding stuff... I don't get any of the first errors (cannot locate realtime modules dir or module path too long) but the last, can't find module.... jmkasunich: Did you see my proposals in the Dirctory.map ? not yet - haven't been online much this week alex_joni: do you have any idea where "moduledir" comes from? he stat's it, then uses it if the stat passes, but I can't find moduledir anywhere it comes from Makefile.inc I think oh... #include "../../config.h" yes.. there * jmkasunich doesn't like that paul_c: which branch? main trunk * alex_joni doesn't like that either It's only for language translations you mean the i18n stuff? seems good to me although... I first thought this is about RTLIB is "po" a convention for i18n? need src/po and tcl/msgcat jmk: yes (about po) * jmkasunich knows nothing about i18n I wonder how it will be done in the kernel modules? It won't what? i18n? you don't want to go there ;) I would be happy if the user interface benefits from i18n that's a lot... could it be done at compile time: "./configure --language=en" sure there is some i18n in configure.in already Language support needs (must) be a run time thing paul_c: what if you need to compile with messages in a different language? Messages intended for the "user" will come via the usr interface * jmkasunich is thinking of a) messages in the kernel logs, and b) messages initiated in kernel space and passed up to user space for display to users a) would need to be handled at compile time, and could be ignored (english always) b) could possibly be translated in user space (maybe it isn't actually a message, just a message number, and the user space code looks up the actual text) surely, the option of kernel messages in Hungarian is worht pursuing? lol * jmkasunich smacks robin_sz only if you use Hungarian notation of the variables * alex_joni fears a smack himself... * paul_c asks asdfqwega for the use of his cattle prod does the linux kernel do i18n of log messages (ie, can you build a Hungarian kernel?) now thats something to remember "a Hungarian kernel" lol paul_c: Sure. [hands it over] probably. but it will be more devious than your average kernel maybe a Greek gcc to compile a Hungarian kernel... listening to you guys, I think I need to read up again on what HAL is. a Hungarian Abstraction Layer :)) I've been trying to add Greek as a languge type to an app. recently ... nightmare * robin_z points out he is of Hungarian abstraction ... * alex_joni is too... * alex_joni is too... some 25% kewl ;) 50% here ... and all along I thought "Szmeti" was a nice British name * asdfqwega rolls his eyes... anyway ... we digress ... I never would have guessed :D ;) well.. back to loadrt what, who's Hungarian in here? Don't ask Serb and Croat a coupld generations back andras surely doesn't sound like hungarian lol I was hungarian, but then I et lunch. doh well ... back to loadrt ... that's why I want a hal.conf sitting somewhere (maybe in /etc) sounds about right seems it's running now I exported HALRTMOD_DIR=... I always saw the RT side as a service that should be started at boot time, perhaps from /etc/init.d .. things then connect to it I'll add it to the make run here's a thought: that's how it's thought off when you insmod hal_lib, pass it the path to the rtmoddir then halcmd can ask hal_lib for the path hmmm... or put that in /etc/hal.d/ ? neah... thinking about run in place tho... RT = scripts/realtime if installed, hal.conf would be in /etc that can go to /etc/init.d 'k if run-in-place, it would be somewhere else how do you feel about make test? not to happy hmmm its pretty much a standard ... robin_z: make test is not what you think (wish) it is 'k make test does a "test install" as a way around the fact that "make all" no longer generates something that can run where it was compiled hmmm * robin_z goes for tea you should be able to do "make" and then run the new code, once happy, do make install to install it the run-in-place must not conflict with an existing install you can run make run :D which doesn't conflict with nothing... * jmkasunich needs to add version checking to hal shared memory but I admit it needs some tweaking I don't like the env thing... me neither the whole loadrt command is a kluge right now I switched to another console ... and emc isn't running anymore huh? switch to other console, switch back, and emc is dead? no... switch to other console, and run emc from there that's cause the export doesn't extend to the other console no export HAL_RTDIR_ stuff there so it fails.. I know.. that's why I don't like it maybe add the export to emc.run ? when installing emc.run? perhaps with the proper dir... the problem is that we're starting to decline into ah-hocery quick question: does Tim Goldstein pop in here now and then, or can I reach him on another irc channel? into what? Tim who ? :) never seen him here - I think he went away from emc a couple years ago You would need to email him direct ok thanks alex_joni: ad-hockery as hoc literally means "for this" unless it is an easy question ad hoc in other words, band-aids, instead of well thought out general solutions yup... same impression here "band-aids" = "Sticky plaster" plaster is for walls ;-) ok.. let's chew this through... halcmd needs to load the module right? I see one specific problem: how does halcmd loadrt know where to find it's modules but the general problem is "how does any part of emc find it's other parts" well... it can be based on directory.map technically, halcmd doesn't need to do the load, you could use insmod directly but loadrt makes things cleaner but... when you install .. things get moved note that loadrt can make things more secure too make sure it's a hal_module, etc right that's why I want hal modules in a different dir than other kernel modules deffinately can we make a list of other related issues - other programs and scripts that need to find specific paths? smthg like /lib/modules/`uname -r`/emc or /../rtai/emc where .. is module dir yeah * jmkasunich looks at install.map and directory.mal and I don't really like everything copied into /usr/local/bin/ I would love /usr/local/emc/bin and /usr/local/emc/etc, /lib, /man, /share maybe /opt/emc but then you have to add /usr/local/emc/bin to the PATH hmmm.. yes not good either there's a crap load of tcl files... I didn't realize there were so many most are not needed for emc to run they are usefull ... but not needed maybe put those somewhere else? I'm the wrong person to ask don't know much about the Linux Filesystem Hierchary can't spell it either lol... well.. me neither LFSH that's easier to spell - but I still don't know crap about it paul_c: hope you didn't write that pot file by hand... Of couse every single line... script? paul_c: what is the url for LFSH? was tagged and then run through xgettext * alex_joni is watching http://www.gnn.tv/content/emosh_hi.html one sec jmkasunich http://www.tldp.org/guides.html http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html I notice that /proc doesn't appear in the root directory (even as optional) For a very god reason /god/good/ enlighten me It is a virtual filesystem that does not exist until the kernel is loaded procfs how common is /proc today? would we be shooting ourselves in the foot if we relied on it? There is a move towards /sys in the 2.6 kernel but /proc is still around does /sys replace proc? It is unlikely to disappear overnight - Too many apps rely on it. that's not encouraging tho - disappering whether overnight or not isn't good /sys is not a replacement for /proc I was wondering about /proc as as way for the kernel parts of the refactored hal to communicate with user space programs like halcmd lists of pins, signals, etc No. care to elaborate? Use /proc for status info and small amounts of config data For example, a /proc entry could be used to display the current configuration "configuration" for hal means the list of modules loaded and the lists of pins, signals, etc but I would caution against using it as a means to pass config data to the kernel modules. we digress * jmkasunich reads LFHS LFSH says /usr/etc (and by extension /usr/local/etc) are virtually unused these days yip how was the tea? /opt is getting a bit thin as well .. not managed to even eat it yet .. small children interfered ... hmmmmm - a thought for the halcmd loadrt problem /proc/hal/module_path (created by the hal_lib module, which must be loaded before any HAL stuff works) contains the path to the hal modules I think hal.conf can also solve the problem but where does hal.conf go? I added a HAL_RTMOD_DIR=// into hal.conf depends jmkasunich: Might work as long as /proc has been mounted when installed it goes to /usr/local/etc or even /etc/hal/ that has to be decided and when running in place? right now it's modified by configure and by make test which installs it in /test/usr/local/etc and how does a halcmd or a script know which one to use well emc.run get's modified by make install there's a sed command inside make install (actually more) what's interesting is that there can be only one _loaded_ hal_lib.o kernel module, even if there are bunches on the disk (one installed, multiples that have been compiled in different trees) once a particular hal_lib.o has been loaded, that should determine what modules are used (I think?) hmmm.. and how does hal_lib know? lol should the loading of hal_lib specify the path? maybe all I'm doing is moving the problem upstream but insmod hal_lib rtlibpath=foo isn't out of the question that command would normally be part of the realtime script which has to know the paths anyway (I think) * jmkasunich backs up a step what determines whether you are running the installed version or a specific "run-in-place" version of emc? the directory where you issue the emc.run command? or the directory in which the emc.run script resides? no... the fact that emc.run get's modified by install but right now.. there is no run-in-place wait a minute it's a installed-to-temp version I'm not talking about the installed-to-temp stuff, IMO that's something we need to get away from I'm talking about "how should it work" hmmm.. but then we need to think about 2 cases... if I'm in my home directory, /home/John/, and I type "emc.run", I expect the installed version (if any) to run if I'm in /home/John/emcdev/emc2cvs and type ./emc.run, I want to run the version in the emc2cvs tree (run-in-place) fair enough likewise if I'm in /home/John, but I type "emcdev/emc2cvs/emc.run" and the same goes for halcmd, and all the other binaries... If I type "halcmd", I want to run the installed one (presumably in my $PATH), if I type ./halcmd, or /halcmd, I want to run a specific one same goes for the realtime script make sense to you? well.. sure does (all I'm trying to do right now is make sure we're agree about what we want... _then_ we try to figure out how to implement it) okay.. fair enough so... what goes where... should be clear from directory.map and install.map right? maybe if I say "emc.run" I want to run the installed emc.run, which by default reads the installed "emc.ini", and that in turn points to installed "foo.hal" well.. even if things get changed, it's pretty clear right let's presume /usr/local/bin/emc.run OK, but it doesn't matter as long as it is in my $PATH and /usr/local/etc/emc.ini & foo.hal yup same /usr/local/etc/emc.conf, hal.conf, rtapi.conf on the other hand, if I say "cvstree/emc.run", I want it to use cvstree/configs/emc.ini and cvstree/configs/foo.hal maybe /etc/... (but that's a minor problem right now) ok... so we agree that both emc.run are different but how different do they need to be? and when installing emc.run will be parsed and changed from relative to absolute paths IMO, directory.map and install.map should look pretty similar should.. but can they? bc if they are 100% similar... nothing needs to be done suppose we changed the directory.map configs directory to etc and so on... such that the emc.run would mostly use lines like $PREFIX/etc/emc.ini where $PREFIX is either "/usr/local/", or "cvstree/" actually, I think "/usr/local/emc" would be better me too $PREFIX = /usr/local/emc or $PREFIx=. or $PREFIX=cvstree/ but... yeah - and give the installer the option to specify a different prefix, for example if they want to install to /opt/emc instead of /usr/local/emc that's done already but... some things go into different folders e.g. the realtime script into /etc/init.d/ man stuff rtapi.conf - could go to /etc/ bc it's not emc-tied so we basically have two kinds of files: those whose locations are the same whether it is $COMPILE_DIR/foo, or $INSTALL_DIR/foo, and those that aren't the same yup first goal, make as many as possible the same even if that means re-arranging directory.map to look more like install.map I see.. well let's take them one by one... I'm looking at the installed stuff * jmkasunich opens both map files in an editor I have /etc/init.d/realtime actually /etc/rc.d/init.d/realtime (that's the proper way) and /lib/modules/kernelver/rtai/*.o (would like to see an aditional /emc/ ) or emc2 that's the realtime modules? yes blocks, debounce, encoder, etc. hal_lib, etc question: why can't the modules be under /usr/local/emc2/rtmods or something like that (ie. in the same tree as the rest of the installed files, rather than in the kernel module tree) no idea paul? any thoughts on that? in install.map it's under /usr/realtime/modules putting them in the kernel modules tree makes it possible for insmod to find themn but I think in /usr/local you have user stuff so you can do "insmod parport" instead of "insmod /parport.o" yup.. but that doesn't help a lot... if halcmd is gonna do the loading, it will tell insmod exactly where to look * alex_joni thinking about emc.run... note that rtapi.o and hal_lib.o probably should be in the kernel modules path, but the others (parport, encoder, etc) should not hmmm.. modules in /lib/modules/ is very explicite misspelled that one... the user knows what to expect from files there lib/modules is for kernel modules - aka modules that are actually part of the OS or drivers or other _system_ related things our modules are kernel modules in name only - they are actually specific to emc2/hal and of no use to the general system I hope paul_c is listening to this and will comment if I start going somewhere strange If it is kernel space, then it goes in /lib/modules/{KVER}/foo ok what about /lib/modules/{KVER}/emc/foo? so /lib/modules/{KVER}/rtai/emc? so our modules don't clutter up the system modules directory or /lib/modules/{KVER}/emc/ ? it matters not how far up the tree a module is buried as long as it is somewhere in the /lib/modules/{KVER} tree I think KVER may be something like linux-2.4.18-rtai, so the "rtai" part can be skipped KVER=`uname -r` ok diffs between install-dir and make-dir directory.map and install.map how about $BIN-PREFIX $RTMOD-PREFIX $MAN-PREFIX ? as inputs to "make install"? yup sounds reasonable but.. make install uses standard values for those so simply make install just installs the defaults should be the oops the "standard" locations - the prefixes would only be speficied if the user wanted to do something special yes and normally they are void (after make) so run-in-place is possible need at least one more: $EMC_PREFIX, for the files that are in the same place in install.map and directory.map maybe 2 levels are needed $PREFIX/$BIN-PREFIX or smthg like that not a good choice for an example right now: ./configure --prefix=/opt would overwrite the standard /usr/local so $prefix 0 /usr/local s/0/=/ I would think ./configure (or make install) would have something like: if [ ! -n $PREFIX ] ; then $PREFIX=/usr/local ; fi duh if [ -z $PREFIX ] ; then PREFIX=/usr/local ; fi actually there is a : AC_PREFIX_DEFAULT(/usr/local) in configure.in which (when autoconf is run) creates ./configure that contains some code for prefix checking if no other prefix is specified $prefix=/usr/local ok, that's even better you can adjust a lot of dirs this way can you use that for arbitrary variables not like that like AX_FOO_PREFIC_DEFAULT(/somewhere) AC_PREFIX_DEFAULT is only for $prefix s/AX/AC/ bummer but cause we're gonna want BIN_PREFIX, RTMOD_PREFIX, and maybe others you have bindir, sbindir, libexecdir, datadir, sysconfdir, sharedstatedir, localstatedir, libdir, infodir, mandir take a look at Makefile.inc.in and at Makefile.inc sysconfdir is normally /etc, right? nope these all are dirs that can be used by the app defined as $prefix/something sysconfdir=${prefix}/etc hmmm.. maybe that /etc you asked about was relative not absolute? (then yes) if $PREFIX is /usr/local/emc (or /opt/emc) then "sysconfdir" is really "emcconfdir" isn't it? it's /usr/local/emc/etc I thought sysconf meant system wide config stuff, hence /etc ok, just a confusing name well... that's the way the autoguys did it ;) ok binaries that need to be in the users path should go in $BIN_PREFIX, which by default will be "/usr/local/bin" (note no emc), while most other stuff (ini files, etc) will go in $PREFIX which will default to "/usr/local/emc" does that sound right? hmm.. I'm dizzy there is a BIN_DIR and a bindir and now a $BIN_PREFIX maybe I'm confused no.... should it be $BIN_DIR, not $BIN_PREFIX? it's just way too cluttered right now we need to make it simpler oh.. I forgot there's $(DESTDIR)$(TESTDIR)/$(bindir) lol if you take a look at Makefile.inc there are all things twice... we need to loose half of those it's confusing right now the CAPS ones are used when compiling and the other when installing let's rewind... we have bin's... that go to $(prefix)/bin or $(EMC2_HOME)/bin EMC2_HOME is the cvs directory? yes but... problem here are the tcl files the problem is? they used to go to $(EMC2_HOME)/tcl on install they go to $(prefix)/bin a). $(prefix)/tcl or b). $(EMC2_HOME)/bin so we have one case question: do they need to be in the user's $PATH? answer: no idea :-) cause that is a dividing line * alex_joni is looking at the tcl files things that need to be in the path (once installed) go in $BIN_DIR/ (default /usr/local/bin) things that don't need to be in the path go in $prefix/bin or $prefix/tcl there is tkemc.tcl but the user never (that I'm aware of) invokes tkemc from the command line ..... hence it doesn't need to be in the path - emc.run invokes it, and emc.run should know where to look ok... so tcl goes to $(prefix)/tcl ? I'm inclined to think so there is a EMC2_TCL_DIR in emc.run that can be changed actually that comes from emc.conf so... let's try this: look at directory.map, and determine which catagory (below) each directory fall into catagories: emc.run reads the values from emc.conf, hal.conf, rtapi.conf * alex_joni holds 1) same place in directory.map and install.map (only prefix changes) * paul_c will have to leave you guys to it... 2) don't need it at all in install.man (source stuff) ok paul... goodnight. 3) some other place in install.map yes ok... so for 1). bin stuff tcl stuff nc_files (should we install the sample part programs?) etc stuff (was known as configs) yes lib stuff man stuff don't man pages go in the system man dir tree (catagory 3) could go * alex_joni tries smthg if it's in /usr/local/man/ it works too that's what I was thinking $MAN_DIR, with the default being /usr/local/man standard on my machine the man files are in /usr/share/man but... never mind that ;) ./configure could do "man -w if $(prefix) is /usr/local, then man is in category 1 configure does that ok I thought prefix was /usr/local/emc? * jmkasunich is getting confused again it was a if there if $(prefix) is /usr/local/emc then man is in category 3 * jmkasunich looks right now $(prefix) is /usr/local but that can be changed if it makes things clearer/simpler I thought we had decided on /usr/local/emc we can... ok.. define $(prefix)=/usr/local/emc I think it's really important that as much emc stuff as possible be under a /emc/ thing how about bin stuff? that's not in path anymore... if not in $PATH, then /usr/local/emc/bin if in path, then /usr/local/bin keep the number of files that need to be in PATH to a minimum emc.run should be right and probably halcmd nope we can move all to /usr/local/emc/bin sorry... halcmd could be if we want the user to be able to use the system without emc, only with halcmd how about a symlink? or if he's gonna use halcmd from the command line for tweaking thingds yes... symlink sounds like an _excellent_ idea - for both emc.run and halcmd files in $(prefix)/bin ALL binaries in /usr/local/emc/run, and symlink those that need to be in path and symlinks in $PATH s/run/bin s/run/bin/ I hope :P ok moving on how about man stuff? if there's only halcmd.1 there will be more, I hope $MAN_DIR/man.n/filename okay... leaving man stuff in 3) run-in-place ... stays man in docs ? where $MAN_DIR is either /usr/local/man, or is discovered by ./configure yes ok install will just copy docs/man/* to $MAN_DIR/* ok that sorts out $(prefix) stuff now... modules paul said those should go to /lib/modules/KVER/emc/ right? yes so they're catagory 3 yup normaly in rtlib/* I'd prefer KVER/hal instead of KVER/emc, but not gonna fight that battle today hal is ok I said emc, just in order not to put them in /lib/modules/kver/rtai the way it's done now (zwisk did it I think...) let's do hal, if Paul objects we can discuss it ok * jmkasunich edits madly in install.map but I think that would be more a board decision * alex_joni is eager to see install.map I will commit when we finish this discussion - want me to email what I have now? neah... I think I can still remember what we have discussed although... it's pretty late ;) 1:32 am here we need to rename configs to etc any idea how? you want to wind down? I can finish editing, commit, and resume tomorrow no no no under the cvs tree? yup it's easy since no files are actually committed in that dir (I think) * alex_joni is sleepy, but still he sees that this is going the right direction... pitty to stop in configs? I think there are some files commited there... * alex_joni thinks of emc.ini for example oops, I was thinking of another directory * alex_joni opens the red-bean book I think renaming a directory isn't easy not something to figure out at 1:30am - that decision can wait - worst case the files continue to live in configs, but get installed to etc yup.. sounds ok seems https://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_7.html has the answer but better to leave it undone for now... ok... where were we? editing ;-) right I have docs, nc_files, etc, lib and bin under $PREFIX prefix oik and tcl ok done now rt modules cvstree/rtlib is the cvs location yup... RTLIB RTMOD_DIR? and /lib/modules/KVER/hal/ the install location default being /lib/modules/KVER/hal/? there is a moduledir already huh? figured out by ./configure that's where all the kernel modules actually are? no that's where hal modules should go * jmkasunich is getting confused - I thought we just decided that they should go in /lib/modules/KVER/hal ? yes but.. I'm talking about the situation right now oh ./configure searches for rtai or rtlinux modules and finds the moduledir which can / should be used as a target to where the modules should go (when installing) hmm - that's a different set of modules (but we need to know where they are too) * jmkasunich disagrees those modules belong to the RTOS I don't mean that hal modules should go to rtai dir the "realtime" script needs to know where they are but... (and this was paul's point) but the hal modules should go elsewhere when we are compiling for a different kernel let's say compiling from a unpatched kernel we need to find the kernel that has been patched (that already has the rtos-modules) I think I understand and install our modules to the same location (../hal) not `uname -r` blindly and ./configure already does that the default for $RTMOD_DIR should not be /lib/modules/KVER/hal, it should be $moduledir/hal right? and provides a --with-module-dir= almost $moduledir=$rtaimoduledir/../hal $RTMOD_DIR=$moduledir the first line could as well be $rtlinuxmoduledir, or whatever * alex_joni is not sure he makes himself clear... yes! I think moduledir should be the RTOS dir, _without_ /hal e.g. halmoduledir well... the RTOS dir is /lib/modules/kver/rtai do we want to install into /lib/modules/kver/rtai/hal ? oh, I missunderstood the .. in $rtaimoduledir/../hal I think kver/hal is better didn't realize you were backing up one level yes although rtai/hal makes it more clear... (harder to find though) still think moduledir should be $rtaimoduledir/.. I'll change moduledir to halmoduledir then it's clear in any case, there is not really a "default", instead ./configure will set it right? there is a default inside ./configure BTW, we need to decide about upper/lower case if these are env variables, I prefer uppercase yes... but if the autoconf folks have already established a standard, then we should follow that lower case is used for prefixes and stuff, that get changed by make install right now i have a mixture well that's the way it should be... everything lowercase gets replaced by install ok, I'm editing install.map, which shows things as they are installed so I'm gonna use uppercast by the way, these variables are probalby the ones that wind up in rtapi.conf, hal.conf, and emc.conf yes so in install.map, I have $BIN_DIR (default /usr/local/bin) $MAN_DIR (/usr/local/man) $prefix (/usr/local/emc) -- I think that should change to $EMC2_DIR in install.map and $RTMOD_DIR (default rtosmoduledir/../hal) does that make sense? I think you meant $EMC2_DIR in directory.map right? well I was talking about install.map... perhaps it should be $PREFIX? all the others are *_DIR though hold your horses for a minute;) so... when ./configure is done Makefile.inc (and a lot of other files) contain $(prefix) after a make install $(prefix) gets changed with /usr/local after a make install $(prefix) gets changed with /usr/local/emc sorry bout the first one or whatever the user specified - might be /opt or whatever yes so there is no $PREFIX in the installed files we have /usr/local/emc all over the place or whatever will the user specify /opt or whatever at ./configure time, or at make install time? ./configure time it gets then written to Makefile.inc in the installed files, we should have $PREFIX (or whatever - a shell variable) from there included for compiling, and for installing sorry, that's wrong what is? what I started to say about PREFIX I was mixed up - I think I'm starting to get it when we install.. we would need to parse all the scripts and configs to absolute directories so there is no confusion the installed files (scripts, etc) will have NO variable substitution, they will all have absolute directories? right? yes that's how I'd do it that means if you add _any_ new scripts or anything like that, you need to add to the build system to do the substitution at install time the only thing that can't be changed are the already compiled files (those have to rely on configs) yes... but that's easy if you look at how zwisk has done it... in Makefile relatively easy, for somebody how is aware of the need he has a list of scriptfiles but suppose some new developer wants to add a simple script to do something he copies an existing script, uses the same conventions, veriables, etc, and if you add your script there (you need to add it there in order to get it installed) then it gets changed automatically but unless he adds it to the list of scriptfiles, it won't work good point - must be added to install it anyway it should work from run-in-place still need to figure out how to do that now I understand why he needed the make test target and the dummy install directory it's easier ;) he _never_ actually runs the original scripts, only the "installed" ones that have been edited? exactly ewwwww well.... it is something... (better than nothing ;)) I know * jmkasunich tries to think of a better way thing is... I'd like it if the scripts always (installed or not) used variables so the scripts don't get affected? right - no changes when installing them, just copy but now the variables need to get set somehow that's where rtapi.conf and friends would be used yup.. but first problem how do you find friends.conf ? welllll, I'm thinking about that no good answer yet ;-) if installed, you want /etc/foo.conf if not, you want cvsdir/foo.conf which one do you check first? I'd go with ./etc/foo.conf I must admit, having install modify the scripts is a good way of dealing with the problem then /usr/local/emc/etc/foo.conf but both of those are installed locations if you're running an uninstalled version, those are the wrong place I'm begginning to change my mind about modifying the scripts ;) I know why... If the unmodified scripts run in place correctly, then I think modifying them for install is great yup... in order to do that.. we could make something like ${prefix}=/usr/local/emc but if they need modified to run in place, then working on a script is annoying.... edit, make test, run, instead of just edit run $SCRIPT_DIR/bin maybe SCRIPT_DIR is not ok (just an example) and SCRIPT_DIR defaults to $EMC2_HOME but when installing it gets replaced with ${prefix} what do you think? my brain hurts mine too ;) but less.. because it's half asleep one approach that we know will work, but is inconvenient, is the make test approach that treats the CVS version of the script as "source code", in fact it isn't runnable until make test modifies it, right? yup... it's very inconvenient right the trick is to make the "source code" runable I modified hal.conf, and I needed 5 mins. to convince make run to install it again :( here's a thought... what if all the things that get changed are in emc.conf and friends the only thing in emc.run that needs changing is the path to emc.conf and that can be skipped (check local dirs e.g. ./etc/) maybe check from where emc.run was started see lines 18-28 of realtime that's EXACTLY what I was looking at right now but it should be reversed, so it checks for a local .conf file before it checks /etc yup that way run-in-place will find a local conf pointing to local stuff only thing... not to run emc.run(from PATH) from within the cvs-dir usually you run in EMC2_HOME scripts/emc.run * jmkasunich tries a test but if you run emc.run then you got problems * alex_joni was reading through FEST notes... http://linuxcnc.org/spring_EMC_meeting_info.html contains some mail addys those should be removed... noted finally finished my test what test? I think it works, even when you do "emc.run" from within the cvs dir if the one in the path is called, $0 is not "emc.run", it is "/usr/local/bin/emc.run" well... it should run with the cvs stuff... right? I see... if you do ./emc.run, it will run the local one if you do emc.run, it will run the installed one nice ok... now in either case, $0 correctly identified the one thats running so it can get the corresponding conf file(s) can you commit the mod's to directory.map, and install.map ? yes, just a couple more tweaks BTW, my mods are at the end of the file - I copied the original contents and edited the second copy, so the first is unchanged on what branch are you working? autoconf I presume... yes ok is bindir the autoconf name for the directory where the bins are? /usr/local/bin? or is that autoconf's name for the /usr/local/emc/bin? http://www.gnu.org/software/ac-archive/htmldoc/stdrelpaths.html worse ;) it's GNU's standard ok, my head is spinning... I'm gonna just commit what I have, I know some of it is wrong, please fix if you can I'll try... I don't really like the way GNU's done it I have to leave - it's way past dinner time here (and my wife is getting restless) well.. I'll go to bed... OK, talk to you tomorrow yup.. bye Les, you there? Man, there are times being a night-owl stinks. I am here after a 12+ hour day debugging some commercial robotics It's late so I had to work today glitches in digital logic, etc I am doing golf tommorrow!