RE: cross toolchain vs. info files

[Doug Evans <dje at transmeta dot com>]

Dave Korn writes:
 >   Because they may all be very different versions, with different command-line
 > options.  (This applies to Gcc as well, which has more option-churn than
 > binutils, but the point is valid for both).  It is not the same document.

I don't recall GCC ever controlling what target-specific parts of the info docs
to generate/install.  Maybe that's changed.

 > > It's been awhile, but I don't recall any target-specific elements
 > > in any particular man page or info doc.
 > 
 >   It's crawling with them.  Just take a look in /src/gas/doc at all the
 > c-*.texi files, for instance.

Heh.  I was afraid I would get misunderstood - I realize all the
c-*.texi files are there.  That's why I added the next sentence:

 > > what I'm refering to is, 
 > > of course, whether the docs get something extra or different iff that
 > > particular target is configured.]
 > 
 >   Yes, absolutely they do.  Check out all the "@ifset <CPUNAME>" directives in
 > as.texinfo.

Ah.  Generally they're all enabled so all I've ever seen when reading
the installed docs is all the documentation for all the targets.
[e.g. see asconfig.texi]
Does that ever change in practice?

 >   Well, in a way it is; gcc suffers the exact same problem.  But in a far more
 > important way, it isn't.  If you build and install gcc 4.x on a gcc 3.x
 > system, you will indeed have two executables called gcc, and they may clash,
 > but since each one will also have installed an executable with the version
 > number as part of the name, you can still access them, by invoking either
 > gcc-3.3.6 or gcc-4.0.1 or whatever.

OOC, does this happen for every binary gcc installs, e.g. gcov?
If we're gunning for perfection, then let's not waffle. :-)

 > >  If you don't want to clobber your main system tools,
 > > don't configure with, for example, --prefix=/usr. [Assuming, of course,
 > > that 
 > > there is, or may at some future time be, target-independent tools in the
 > > release - One can define the problem away, by requiring every binary to
 > > have the $target- prefix, but I'm not sure the cure is better than the
 > > disease here.] 
 > 
 >   You're missing the point here.  I haven't clobbered my main system tools.
 > The build system is carefully set up so that cross tools can never clash with
 > system tools, and the main part of the way that is done is by prefixing the
 > names.  I don't see why the man/info pages should clash, since for different
 > targets and different versions they *are* different man/info pages.

I think one needs to treat "different targets" and "different
versions" orthogonally.  You're trying to solve the different targets
problem.  But suppose things are fixed as you wish?  You're still not
advocating adding version names to the installed doc files.
One could add them, but in my mind if you're worried about it use a different
path, ergo my point above regarding --prefix.  It applies equally
well to installing a 4.0.1 arm-elf-gcc on top of an existing 3.3.5
version, say.

 > > On a related subject, target libraries and includes go in
 > > $exec_prefix/$target. 
 > > I'm curious if there's any plan to change that to $prefix/$target?
 > > [I can't recall why $exec_prefix/$target was chosen (way back when).
 > > Anyone remember?  Maybe I'm overlooking something.]
 > > [linux hosted target libraries/includes shouldn't be any different than
 > > cygwin hosted target libraries/includes, for example]
 > 
 >   Heh, I really have no idea what the purpose of --exec-prefix is, and since
 > it defaults to being the same as --prefix, I don't ever bother setting it.

Suppose you have a hetergeneous environment with linux, solaris,
sunos, aix, (and hpux for good measure).  There's no point in
installing multiple copies of the same file if they all live under a
common root.
-exec-prefix exists to allow one to put host-specific files in one place
while non-host-specific files can all be shared.