On Sun, Dec 18, 2005 at 12:12:17PM -0500, Richard Kenner wrote: > Backwards compatibility is indeed expensive, but is critical. All vendors > do it and we need to as well. You can be certain that if there were six > ways of specifying something in VMS on a VAX in 1979, all six will still > work today on all VMS targets. There's a reason for that: the users demand > and expect it.
I am perfectly willing to maintain backwards compatibility for _users_ of GCC. Most users of GCC don't build GCC, and most builders of GCC really don't use the full expressiveness of the build system. I disagree with the assertion that we need to maintain "compatibility" in our Makefiles. Obviously we want to in as much as it is practical; this isn't. And don't you think that talking about compatibility expected by our users is just a little bit disingenuous, when you're talking about running make inside the gcc subdirectory? Users don't do that! Only developers of GCC do. It's only useful for incremental builds; a full build of GCC always starts and ends in the top level. > ./configure && > make bootstrap is going to continue working, presumably forever. > > I thought the whole point was that "bootstrap" wasn't a target at the top > level, but just in the gcc/ directory, so that the above did *not* work. Huh? Are you talking about before, or after, the changes? "bootstrap" has always been a target at the top level. It used to be implemented by building a bunch of other stuff and then forwarding to a bootstrap target in the gcc subdirectory and then building another bunch of stuff, but is no longer. > Any such build script - we've got plenty of our own here, thanks - > grows little widgets over time to handle particular configurations and > particular versions of GCC, in my experience. > > Sure, but the issue is the *size* of the differences. Are we talking about > something subtle or a completely different sequence of make targets? Paolo already answered this question, in a message directly to you: http://gcc.gnu.org/ml/gcc/2005-12/msg00490.html > But if you insist that you must continue to run 'make' in the gcc > subdirectory, you won't get a bootstrap, just a rebuild of the current > stage. > > You lost me. "make" in the gcc subdirectory would always build into that > directory using the system compiler (i.e., what you'd normally use to build > the stage1 compiler), not do a bootstrap. It was "make bootstrap" that would > continue the bootstrap from the current location. I was referring to "make $(anything)", i.e. the command /usr/bin/make. > In my experience, the four most common targets in the gcc subdirectory were: > > <empty>, as above > bootstrap, as above > compare, the obvious > unstage1, to undo a "make bootstrap" > > I think those four targets need to keep working because they are also the > oldest targets. I certainly agree that it's reasonable to change the way > that the lesser-used targets are executed, so long as there's a > clearly-documented mapping. However, I also don't see why we can't simply > put that target into gcc/Makefile.in to simply recursively execute the make > with the equivalent target. That does not have the maintenance burden you > suggest above. Because it would have to recurse to the parent directory, which is then going to rename your current directory and do bits elsewhere, in other directories; it's likely to leave you far away from the results of your make. Do you really think that'll leave you any less confused? I'd be baffled! I hate it when things rename my $PWD. -- Daniel Jacobowitz CodeSourcery, LLC
