Re: gcc-2.6.3

[Christian Lynbech <lynbech@daimi.aau.dk>]

(I have changed the order a bit, to start with the main point)

>>>>> "Waldi" == Waldi Ravens <waldi@moacs.indiv.nl.net> writes:

Waldi> Christian Lynbech wrote:
>> /usr/gnu is just one suggestion, others are possible, the main idea is
>> that it should be different from standard directories such as /usr/lib
>> or /usr/local/lib.

Waldi> I'm really puzzled why you don't want to use standard locations. What
Waldi> about configure scripts (for example elm) that search for the libraries
Waldi> in standard locations to find out which functions are supported by your
Waldi> system? Sure, you can add your non-standard paths, but I'd rather prefer
Waldi> a sytem where I can type `configure; make', sit back and enjoy. :-)

I have nothing against standard-locations. It is only that GNU tools
has a common (for recent versions at least), coherent and rather rich
directory layout. It just isn't very standard, in terms of things like
SYSV or BSD.

One of the really nice things about GNU tools, however, is that you
can root this layout anywhere you want, by means of the --prefix option
to configure.

What I really has been trying to say is: use the GNU diretcory layout
for GNU tools. It will mean something to some tools, where configure
actually checks for the presence of other tools, and it will make it
easier to pull raw GNU sources from ftp and install them on your
system, without having to dig through tons of makefiles and readme
files in order to find how the previous version was set up. And you
will avoid having tools jumping around in the system, depending on who
compiled the version you are installing now. 

All of this can remedied by defining a standard saying:

	Thou shalt configure GNU tools with a prefix of XXX

What XXX should is of course not obvious. I prefer /usr/gnu to
separate the two hierarchies (atari/mint/lattice/sozobon/whatever
vs. gnu) on grounds that GNU is working itself towards a single,
complete system. But one could argue for /usr (GNU is the defacto
standard for us) or /usr/local (non-vendor supplied systems go in
/usr/local).



(back to some more detailed comments)

>> I would like to promote letting GCC's configure script decide on the
>> internal organization of the GCC directory, i.e. to select a single
>> prefix, and let configure do its thing from that.

Waldi> It already does (--prefix=XXX). If you use gcc as the sytem C-compiler
Waldi> the most appropriate prefix is /usr, otherwise /usr/local.

I know. But I am guessing from the original posting (Frank Bartels
response to Michael Plonus) that Michael is not just using the
prefix. At least, what Frank proposed would not be a standard GCC
installation, even though it might be perfectly sensible BSD style.

 
>> Note that we are not
>> just talking about binaries, but also libraries and (possibly) include
>> files, perhaps the nbinary utilities and support for GNU's own
>> version/architecture separation scheme.

Waldi> The headers and libraries are not part of the gcc package. At least
Waldi> the gcc I'm using does not include a standard library, it uses the
Waldi> system's standard library (AKA mintlib). The headers are off course
Waldi> shared between gcc and any other C-compilers; in my case gcc acts as
Waldi> the system's C-compiler (/usr/bin/cc), while the others are located
Waldi> on the /usr/local filesystem, but all three are using the same sets
Waldi> of headers in /usr/include and /usr/local/include.

Well, I was thinking of the GCC specific ones. GCC install several
things under $(prefix)/*/gcc-lib/*. Apart from the compiler binaries,
this includes libgcc.a and fixed includefiles, and it was only these I
was referring to (not that that was obvious).



------------------------------------------------------------------------------
Christian Lynbech               | Hit the philistines three times over the 
office: R0.33 (phone: 3217)	| head with the Elisp reference manual.
email: lynbech@daimi.aau.dk	|        - petonic@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------