The answer to both of these questions is the same. Toplevel bootstrap
deliberately - as a design decision, and in my opinion, a very good
one - puts every stage in its own directory.
Of course: we've always had each stage living in a different directory.
You're not going to get any disagreement there. My question was why you have
to go *up*. Unless you're rebuilding a library outside the gcc/ directory,
all the stages can be in subdirectories of that directory.
Instead of trying to move all the object files we're staging into a
subdirectory, each stage of gcc is built in its own directory.
I'm not sure I see the difference there, but OK, as long as it doesn't
complicate anything else.
This lets us not have to guess which files need to be moved and which
(e.g. generated by configure) need to be left alone. For GCC we
already knew what this list is, by exhaustive trial and error.
As you say, we know it, so it "ain't broken". That list is only very rarely
changed, but if there's a concern about maintaining it, I think the
straightforward approach is to take the very few things that *are* to be left
alone and put them in a directory of their own. Then you can copy everything
in the build directory into a stage directory. So you have ., where things
are built, ./invar, which are the things that are kept the same through the
process, and ./stage[123], which is where the built stages are put.
For other directories, however, we don't want to have to work it out.
It lets the bootstrap mechanism be more modularly independent of the
components being bootstrapped.
Here you've lost me completely. When you say "bootstrap", I interpret that
as meaning using X to build another copy of X from sources enough times so
that you can compare successive versions and expect them to be the same. But
what else is there in the gcc tree that can be used to build itself? So
what's to be made "independent"?
Therefore, you get obj/stage1-gcc and obj/stage2-gcc. And via either
symlinks or directory renames (and it looks like we'll have to switch
back to only via directory renames) one of these is obj/gcc and
another is obj/prev-gcc at any given time.
What's wrong with the present obj/gcc/stage1 and obj/gcc/stage2? As I said,
I think renaming directories is going to cause no end of problems (having
directories be renamed under people is just one example). What's the
benefit? Before we made "make bootstrap" restart in the beginning, the
Makefile was able to keep track internally of what it was up to. More
recently, we used a file that stays where we are. What's so wrong with that
approach that justifies renaming directories? Can't those two states
(current and previous) just be variables in the Makefile that it imports
from some status file?
