This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: what should bootstrap *really* do?
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: what should bootstrap *really* do?
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 15 Nov 2000 11:56:50 +0000
- Cc: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>, gcc at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
aoliva@redhat.com said:
> This of all those folks who have flakey problems that cause the build
> to fail at random. Think of people who build GCC on MS-Windows. Think
> of people who want to report a problem, but the error message has just
> run off their screen. Why should they have to restart bootstrap from
> scratch? My (unproved) claim is that the number of people in this
> kind of situation surpasses the number of people who make a minor
> change here or there, that would require bootstrap to be restarted, so
> we should privilege this (alleged) majority with the default behavior
> of `make bootstrap'.
I don't understand why the whole thing has to be so complicated. Why
won't the following model work?
bootstrap:
if test ! -f stage1.completed; then \
$MAKE_FOR_STAGE1 ; \
make stage1; \
fi
if test ! -f stage2.completed; then \
$MAKE_FOR_STAGE2 ; \
make stage2;\
fi
...
stage1:
NORMAL_MOVES
touch stage1.completed
clean:
NORMAL_CLEANS
rm stage1.completed ...
Then only the stage rules create funny stamps, meaning that any step of
the bootstrap can be repeated until the stageN rule is run.
You could then easily have
unstage1:
if test -f stage1.completed; then \
make mostlyclean; \
RULES to move stage1/* back to current dir; \
rm stage1.completed; \
fi
This model requires two new stamp files (rather than the current 5 or 6),
and they correspond well with the rules that create them.
R.