Dear Forum,

Franz Gaehler writes:
> > For purposes of network installations one often even does not want the full
> > release number of the OS (There were times when our network had machines
> > with linux 2.0.30, 2.0.32, 2.0.34 and 2.0.35) but something weaker. The best
> > way around this is to link all these potential directory names to the same
> > directory.
>
> I find it most convenient to use the variable $HOSTTYPE available in
> most Unix shells. That is, I set GAP_PRG=$HOSTTYPE/gap in gap.sh,
> and in <gap_home>/bin I put for every value of $HOSTTYPE that might
> occur a symbolic link to the right directory. For instance, there is
> a link i386-linux -> i586-unknown-linux2.0.33-gcc on my system, and
> another one i586 -> i586-unknown-linux2.0.33-gcc. This covers all
> linux machines. This is much simpler than hostnames or compiler/kernel
> combinations.

As I wrote in my message, hostnames are really not a good choice, and
the GAP developers seemed to have agreed.

As far as compiler names in the path, they seem to prefer
to keep them, for the purpose of facilitating debugging and
development.
What is the best for development, need not be the best
for the users/administrators. A former collegue of mine used to use
indecent words in comments in his source.
And once the customer found them there :-)

Some building information seems to be incorporated into the
executable, and is displayed (the compiler name, certainly)
when you start gap. Thus the compiler
substring can be dropped (in the external distributions), as for
debugging purposes that would almost suffice.
I would say that the output of "cc -v" better be
included, as the compiler can be upgraded after the gap executable
is built; say my gcc is now "gcc version egcs-2.91.60",
and the gap is built with gcc version 2.7.2.1.
And this seem to be recorded nowhere, not even in
config.log. (Well, not for all C-compilers "-v" means the same
as for gcc, unfortunately.)

However, kernel names might still be important, in order to safeguard
for external libraries compatibility (so that there is no attempts to
use wrong libc, or something like this.)

----------------------------------------------------------------
And onther question. Perhaps it's the time to have 
"install" target in the GAP Makefile, after all...

Best regards,
Dmitrii

Miles-Receive-Header: reply