From: EBo <eb...@sa...> - 2014-01-30 08:26:22
|
On Jan 29 2014 11:17 PM, John Morris wrote: > On 01/29/2014 05:44 PM, EBo wrote: >> On Jan 29 2014 3:44 PM, John Morris wrote: >>> When I get around to it, I'll make an argument to merge RIP builds >>> and system installs; in this case, RIP builds would be like system >>> installs, but with ${prefix} perhaps set to the top level of the >>> source tree. That will help prevent divergence between RIP and >>> system builds, and make it much more likely that a less-commonly >>> used prefix like /opt/linuxcnc would operate as it should. >> >> One addition aldvantage would be a consistent install path. If the >> UB >> did a pre-install of everything in the LCNC tree, then they would be >> the >> same -- ie: >> >> ${SOURCE}/build/bin >> lib >> share >> doc >> ... >> or some such, > > Yes! Consistency would simplify configure.in, the Makefile and the > run-time scripts, at least. Problems with system installs that > aren't > revealed in RIP builds and the unit tests would be nearly eliminated > (one of those popped up just this evening). And in case wacky folk > like > you and me use distros other than Ubuntu, the job of porting is > greatly > simplified. > > I haven't thought it out carefully, but my instinct is that if done > right, the sequence would be a somewhat complex './configure' > command, > followed by a more or less familiar 'make', 'make install', and 'make > setuid' (unless that's folded into 'make install'). No, it does not need to be complex at all. There are standard predefinitions for all these variables list below (${sysconfdir}, ${bindir}, ${libdir}, ${datadir}, etc.) are typically defined something like: bindir = ${prefix}/bin/ libdir = ${prefix}/lib/ ... unless specifically overwritten, and if I am not mistaken autoconf handles that as part of its standard interface macros. We just need to use the proper config variables. The point is that you simplify the config and use the standard definitions. The place that might need to be tweaked is that you may need to update hard coded paths in your code/scripts. That should be repetitively simple though once the other stuff gets cleaned up. > Then, 'rip-environment' or the equivalent script would simply add the > ${prefix}/bin directory to $PATH, and everything else would fall into > place. > > Off the top of my head, the './configure' command line at least would > need to specify ${prefix} and ${sysconfdir}, but it sounds like you > wouldn't be challenged by needing to add the '--prefix=/opt/linuxcnc > --sysconfdir=/opt/linuxcnc/etc' arguments. Since "sysconfdir = ${prefix}/etc" you do not even have to do that unless it is someplace completely different (like $[prefix}/share/LinuxCNC/config). > For folks (like many of us on this list) wanting something like the > RIP > build, maybe since the 'rip-environment' script might no longer be > needed at run-time, it wouldn't be too much to replace a complicated > complicated './configure' command with e.g. a './rip-configure' > convenience script that runs ./configure with auto-generated RIP-like > paths. If there is a consistent preinstall directory structure, then the only difference between a ${WHATEVER_HOME} and the standard install is that WHATEVER_HOME is set to the source directory before running the scripts/programs. >> then the LINUCCNC_HOME would have a consistent meaning. >> Also, I think we should take the opportunity to remove the EMC >> reference... > > I'll also advocate for getting rid of $EMC2_HOME or $LINUXCNC_HOME in > favor of ${prefix} and family. For a system install, ${prefix} isn't > a > perfect equivalent of the $EMC2_HOME common base directory. The Red > Hat > packages (Ubuntu should be similar) install into /etc, > /usr/{bin,lib,share}, where ${prefix} is /usr. Instead, those > directories have standard names in autoconf like ${sysconfdir}, > ${bindir}, ${libdir}, ${datadir}, respectively, that are similarly > (with > occasional variation) defined on all UNIX varieties that GNU software > runs on. > > Ideally, removing $EMC2_HOME would be an invisible change to users, > and > not a big stretch for developers, most of whom are familiar with the > above autoconf variables, anyway. If not, I'd like to hear > counter-examples. my 2c is that it would remove a few of the lingering issues surounding RIP and standard installs. > Anyway, this is down the road (sorry EBo!), and no, I won't try to > slip > it into the UBC3 branch before 2.6. ;) Well, you cannot blame a guy for trying ;-) Let me know when you are ready to work on this and I will see if I can break away some time... EBo -- |