On Sun, Dec 18, 2005 at 01:25:36PM -0500, Richard Kenner wrote: > 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.
No, that's not at all what we do today. We build everything in gcc/ and shuffle the files off to other directories depending on the current stage. In the revised model, the stages are completely independent; the directories have nothing in common. > 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"? No! This is the old model of bootstrap: rebuild gcc a bunch of times with itself. The top level bootstrap model is to rebuild all the useful bits of the entire tree as a group; and repeat that as many times as necessary to be able to compare them. We bootstrap everything used in the build process. Some example consequences of this: We used to have some workarounds in the libcpp-to-gcc interface to work around the fact that we built libcpp once, with the system compiler, and then linked it to each stage of the bootstrap. Darwin had a system compiler that disagreed with the FSF GCC on the size of _Bool, I believe. Now we build the stage1 libcpp with the system compiler, build the stage1 gcc with the system compiler, link them together, and go on to build the stage2 libcpp with the stage1 gcc. We can bootstrap the assembler in a combined tree. The first stage's gcc will invoke a stage1 assembler, the second stage's gcc will invoke a stage2 assembler. This doesn't have any fundamental benefits except for thoroughness; it's an even better sanity check. Eventually I expect we'll have at least one frontend written in C++. We'll be able to build that frontend using a bootstrapped copy of libstdc++. > 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? It was an implementation decision to use obj/stage1-gcc instead of obj/gcc/stage1, so that (A) we didn't have to move every individual file around, and (B) we knew, robustly, that each stage's build would be completely separate from the previous stage's (no way to leave stray files behind, since the directory is created from scratch). Personally, I think this layout (which I did not pick) is superior. It makes it far more difficult to accidentally mix stages. We could change that decision, and move all the files around instead. That wouldn't change the need to hand off to the top level in order to do bootstraps though; the routines in gcc would be just for convenience. A bootstrap would need to build top level versions of helper tools and libraries. -- Daniel Jacobowitz CodeSourcery, LLC
