This is the mail archive of the gcc@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: what should bootstrap *really* do?



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.


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