This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Important comment update to gcc/configure.in
Alexandre Oliva wrote:
On Mar 14, 2003, Nathanael Nerode <neroden at twcny dot rr dot com> wrote:
Ah, but that's what the version checks are for. :-) For when we are
building a brand new HOST->TARGET gas and can't run it.
Whenever HOST != BUILD, we need a BUILD->TARGET that the compiler is
going to use to build object files for the target. Whether it's
exactly the same as the HOST->TARGET assembler we're about to build
doesn't matter all that much, but the assumption is that it's as close
an approximation as possible. Since we're going to use this
BUILD->TARGET assembler at build time, and the resulting compiler is
going to use a HOST->TARGET assembler we're about to build, they'd
better be fully compatible, so it doesn't matter all that much how we
Actually, this doesn't follow. The generated *object files* must be
fully compatible. The assemblers don't even need to accept the same
syntax, really. (Although life is simpler if they do.)
test the assembler. We can test the BUILD->TARGET one for features,
or the HOST->TARGET one for version numbers, or both and pick the
worst (or flag in case they differ).
Flagging is possibly a good choice, but would indeed cause complication.
However, given the assumption
that they should be the same, I believe it's good enough to keep it
simple and just test the assembler for features. In the Canadian
cross case, this means testing the BUILD->TARGET assembler.
I certainly want to separate tests of the build->target assembler,
used for building libgcc2, from tests of the host->target assembler,
used to determine the behavior of the newly built gcc. Those two
things shouldn't be confounded
I suspect it would be nearly impossible to do away with the confusion,
It should be possible. I see my way clear.
and I actually fail to see the point of introducing so much
complication.
I don't think there is in fact any complication; this is simply
clarification of what's what.
I believe that the first simplification I can get out of this is
elimination, or at least massive cleanup, of the baroque methods used to
search for the assembler. If we're looking for a build->target
assembler, we include ../config/acx.m4 and call
NCN_CHECK_TARGET_TOOL([AS_FOR_TARGET],as). If we're looking for a
host->target compiler, we do something different but equally simple. We
don't do the confounded mish-mash currently in use.
The proper procedure to build a Canadian cross is to
build BUILD->HOST, use that to build BUILD->TARGET,
^^^^^^^^
Um... no. Try again.
and then, using
both, build HOST->TARGET, so it's ok to assume BUILD->TARGET has the
same features as HOST->TARGET.
I think this is really the wrong direction to go in. What I've found is
that the clearest, most managable, configuration code is written by
clearly delineating what you're testing (build/host/target-wise), and
then defaulting one from another in the appropriate cases, rather than
deliberately confounding the tests right off the bat.
Consider a crossback (build=target!=host). This should work cleanly and
simply. It generally doesn't, and it's confounded tests like the
assembler tests which are the main reason.
I'm going to submit a revised comment update patch sometime soon.
--Nathanael