This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GNAT: automatically build source generation tools
- To: guerby at acm dot org
- Subject: Re: GNAT: automatically build source generation tools
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Thu, 4 Oct 01 08:40:03 EDT
- Cc: gcc-patches at gcc dot gnu dot org
I'll expand my comment here. The idea is that if you -I srcdir, you'll
get in the way runtime sources of the new compiler, and they don't mix
with those of the build compiler.
That's actually not an issue because, as you may remember, the
compiler itself uses the "wrong" library: it uses the default library
instead of the proper one for the host machine. But the compiler's
choice of what library routines to use takes this into account, so
it's actually OK. The same is true for those four programs.
However, you are correct that we don't want the .o and .ali files in the
source directory. What's unique here is that unlike the other files that
are built, this generates temporary files. So that's troublesome.
Also, unlike the other files, these *do* differ on different build
(though not host or target) machine, so the binaries certainly
shouldn't go into the source directory, which either doesn't leave a
good place to put them even aside from the tempories.
Actually, I suppose they could go into the build directory with a status of
something like genrecog, but the difference is that the output of genrecog
of target-specific, so it goes into the build directory, but the output
of these are target-independent, so they can go into the source directory.
It's for all these reasons that they aren't in the Makefile now.
We could perhaps put in a new rule "developer-tool-build" that builds them,
but my feeling is to leave it alone for now: it's just too messy.