Re: Partial autoconf transition thoughts

[Alexandre Oliva <aoliva@redhat.com>]

On Jun 14, 2003, "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> wrote:

>  Well, --target-exec-prefix isn't really needed as binaries for a given
> target are already installed under $exec_prefix/$target_alias.

The problem is precisely that we have, in the same directory, binaries
in the host's format, that support the target binary format (e.g.,
bin/as, bin/ld), and libraries in the target format, that are
installed inside exec_prefix even though they're in no way specific to
the host on which they were build.  They'd probably be better off in
${prefix}/${target_alias}, but --target-exec-prefix could override
this.

> For host libraries to be installed on a different build I'm doing away
> with specifying --prefix=/usr/<host_alias>

prefix should not have to be host-specific.  prefix is
host-independent.  exec_prefix is host-dependent.

> I want headers to be
> tightly coupled with their respective headers as there may be differences
> across library versions and sometimes even differences between host
> configurations (bfd.h is an example).

This seems to imply that bfd.h is host-(and target?-)specific, and
should therefore be installed somewhere in ${exec_prefix}, not in
${includedir}.

>> --exec-prefix specifies where machine-dependent files should be
>> installed.  By definition, build files are not installed.  Host and

>  Of course they don't.  They already are installed.

>> Target files are.  Host files are machine-dependent, therefore they go
>> in exec-prefix.  Target files are host-independent, but they are
>> machine-dependent, so there's room for installing them in either
>> prefix or exec-prefix.

>  Pure target files are rare.  An example are the files in
> $exec_prefix/lib/ldscripts.  I'm not writing of them as they are pretty
> obvious to handle.

Target files are machine-dependent, indeed, but they're dependent on
the target machine, not on the host machine.  Take, for example,
libstdc++.a or libc.a, from a x-sh-elf build hosted on say both
i686-pc-linux-gnu and i686-pc-freebsd.  There's no reason to have two
copies of these files, one in say (*)
${prefix}/H-i686-pc-linux-gnu/sh-elf/lib, another in
${prefix}/H-i686-pc-freebsd/sh-elf/lib.  They might very well be in
${prefix}/sh-elf/lib or, maybe, ${prefix}/T-sh-elf/lib.  The point is
that we should have the same libc.a, regardless of whether it was
built along with the i686-pc-linux-gnu, i686-pc-freebsd or yet another
x-sh-elf toolchain that I haven't mentioned.

(*) assume:
  prefix=/nfs/toolchains
  exec-prefix=${prefix}/H-${host_alias}

Still, we do want assemblers and linkers for sh-elf to be in
host-specific directories, which is why they get installed in
${exec_prefix} and, since they're target-specific, in the
sub-directory thereof named after the target:
${exec_prefix}/${target_alias}.  Note that, by using different
exec-prefix for different hosts, we get binaries for i686-pc-linux-gnu
and i686-pc-freebsd in separate directories, even if we use a shared
install tree.

>> > There is a lot of confusion in understanding what
>> > is build, host and target
>> 
>> It shows :-)

>  I don't think so.  What I think is we both understand the meanings right,
> but we have troubles communicating descriptions of specific circumstances. 

I'm trying to give specific examples in my e-mail, let's see whether
it helps us communicate.  I hope you didn't take any offense in my
joke above, btw :-)

>> Can you install binaries for two different machines in the same tree?

>  What do you mean by "two different machines?"

A shared nfs directory containing toolchains for several different
hosts and targets.  Picture building crosses (and natives) hosted on a
dozen different architectures, to a dozen different targets, all
installed in a single directory tree, /nfs/toolchains.

>  Two different host machines?  Of course I can.  E.g. I have both a
> mipsel-linux-glibc-devel and an alpha-linux-glibc-devel package installed. 
> They support development for their respective hosts.

These are libraries for the targets.  I was talking about binaries
built for different hosts, i.e., that would enable you to use this
(shared) /nfs/toolchains tree on machines of all these different host
types, where they'd play the role of build machines.

> They are in fact
> "noarch" packages as they don't care of the build system.

That's exactly why such packages should be in ${prefix}, not
${exec_prefix}.  Anything that goes in ${exec_prefix} shouldn't be
noarch.

>  I think I can see where the divergence lies.  I interpret the definitions
> of a build, a host and a target very strictly,

Part of the problem is that it can't be that strict.  See, when you
configure a toolchain with --build=B --host=H --target=T, build, host
and target make sense for this toolchain build.  For the libraries
built as part of the toolchain, you get --build=B --host=T
[--with-cross-host=H].  So T is the library's host, since the target
library is in T's format.  Then, when you install this toolchain on a
H machine and use it to create another program, you'll configure this
program with --build=H --host=T.  It shifts.  You already knew that,
but I wanted to point out that the definitions aren't all that strict.
They change depending on how you look at it.  What doesn't change is
that ${prefix} should contain noarch files, whereas ${exec_prefix}
should contain files that, should exec-prefix be equal to prefix,
would (potentially) vary depending on which arch's package you've
installed, i.e., depending on the host for which they were build.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer