www.digitalmars.com         C & C++   DMDScript  

D.gnu - Install Location (again)

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
If one is bundling GCC with GDC, would it
be better to have it install in two dirs:

/opt/gcc/
/opt/gdc/

Just like it is being done now on Windows,
when you install the Digital Mars compilers:

C:\dm\
C:\dmd\


Or should everything install in just one
location, say /opt/gnu, for everything ?
(the upside to this is that it is easy to
add e.g. GNU Make and GDB too, later on...)

Under each dir, there would be the usual:
/opt/gnu/bin/*
/opt/gnu/lib/*
/opt/gnu/include/*
/opt/gnu/share/*


For a binary release, I'm leaning towards
using just one single $PREFIX (=/opt/gnu),
since this approach seems to have worked
good for the Fink and DarwinPorts projects ?

One less set of PATHs to set up, as well...
(to find the executables and the libraries)

This was assuming that the regular /usr
won't work, otherwise that would be the
preferred location - if the rest of the
system tools and libraries are "usable".

For the general case, I think we'll need
to bundle the *same* version of GNU C/C++


Thoughts ?
--anders
Apr 20 2006
parent reply Philip Van Hoof <spam pvanhoof.be> writes:
On Thu, 2006-04-20 at 10:21 +0200, Anders F Björklund wrote:

 If one is bundling GCC with GDC, would it
 be better to have it install in two dirs:
 
 /opt/gcc/
 /opt/gdc/


If you are bundling and then packaging it (for a specific distribution),
you should probably install it in $(prefix)/lib/gdc/ and create symlinks
to $(prefix)/bin, $(prefix)/include and $(prefix)/lib as in that case
the bundled gcc is support code for the application (gdc) itself.

For packages you really don't want to step outside of your $(prefix). So
using /opt isn't really the right thing todo (for packages).

So with $(prefix) set to /usr you get:

/usr/lib/gdc/bin/ and /usr/lib/gdc/lib/ and if possible /usr/include/
and /usr/share and then create symlinks from /usr/lib/gdc/bin/
to /usr/bin (but don't do such symlinks for files like gcc and c++ as
such symlinks would certainly conflict with existing packages).

You could do a symlink like /usr/lib/gdc/bin/gcc to /usr/bin/gdc-gcc
and /usr/lib/gdc/bin/gdb to /usr/bin/gdc-gdb . . . :-\

I don't know whether such a bundled install will be usable with existing
tools like gdb, gcc and c++. I'm guessing it's not.


 Just like it is being done now on Windows,
 when you install the Digital Mars compilers:
 
 C:\dm\
 C:\dmd\



 Or should everything install in just one
 location, say /opt/gnu, for everything ?
 (the upside to this is that it is easy to
 add e.g. GNU Make and GDB too, later on...)
 
 Under each dir, there would be the usual:
 /opt/gnu/bin/*
 /opt/gnu/lib/*
 /opt/gnu/include/*
 /opt/gnu/share/*
 
 
 For a binary release, I'm leaning towards
 using just one single $PREFIX (=/opt/gnu),
 since this approach seems to have worked
 good for the Fink and DarwinPorts projects ?
 
 One less set of PATHs to set up, as well...
 (to find the executables and the libraries)
 
 This was assuming that the regular /usr
 won't work, otherwise that would be the
 preferred location - if the rest of the
 system tools and libraries are "usable".
 
 For the general case, I think we'll need
 to bundle the *same* version of GNU C/C++
 
 
 Thoughts ?
 --anders
Apr 20 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Philip Van Hoof wrote:


 If you are bundling and then packaging it (for a specific distribution),
 you should probably install it in $(prefix)/lib/gdc/ and create symlinks
 to $(prefix)/bin, $(prefix)/include and $(prefix)/lib as in that case
 the bundled gcc is support code for the application (gdc) itself.
 
 For packages you really don't want to step outside of your $(prefix). So
 using /opt isn't really the right thing todo (for packages).


Nah, this was assuming that (ordinary) packages would not work,
since $(prefix)/bin/gcc and $(prefix)/lib/gcc would be "taken"...


 /usr/lib/gdc/bin/ and /usr/lib/gdc/lib/ and if possible /usr/include/
 and /usr/share and then create symlinks from /usr/lib/gdc/bin/
 to /usr/bin (but don't do such symlinks for files like gcc and c++ as
 such symlinks would certainly conflict with existing packages).
 
 You could do a symlink like /usr/lib/gdc/bin/gcc to /usr/bin/gdc-gcc
 and /usr/lib/gdc/bin/gdb to /usr/bin/gdc-gdb . . . :-\


I'm not sure what creating those symlinks would add, beyond complexity ?
Adding prefixes is *one* option, but it's not a very attractive one...

--anders
Apr 20 2006