This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GNAT: automatically build source generation tools


    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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]