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').
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.
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.
> 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.
Anyway, this is down the road (sorry EBo!), and no, I won't try to slip
it into the UBC3 branch before 2.6. ;)
John
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
