Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 May 1996 21:55:52 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        current@FreeBSD.org, phk@critter.tfs.com
Subject:   Re: cvs commit: src/bin/sh Makefile arith_lex.l
Message-ID:  <199605311155.VAA02361@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>>   Modified:    bin/sh    Makefile arith_lex.l
>>   Log:
>>   Use new yacc rules. (I'm fixing the tree as fast as I can :-)

>The tree will be broken until I get through all of the changes that
>need to happen.  The breakage is minor but extensive.  
>...
>Sorry about this, but it's all done for a better and more parallel future.

I think there's still a problem with the rm -f and mv part of the rules.
Standard, shared and profiled objects are apparently independent, but
building them involves creating and removing or moving the same temporary
files.

Another bug in this area seems to be larger now.  Try this in a library
directory that has some lex and/or yacc stuff, e.g., libforms (you may
have to set NOPROFILE to get the same results as me):

	rm obj/.depend
	make clean
	make			# everything should be up to date now
	make			# but this builds some things again
	make			# no more

First the standard objects are built.  The intermediate .c files are
(correctly) removed.  Next the shared objects are built.  The intermediate
yacc .c files are (incorrectly) renamed (in libforms, parser.tab.c ->
parser.c).  The intermediate lex .c file is (incorrectly) left alone.
Then the second `make' finds the .o files out of date with the .c files
and prefers to use the .c.o rules to the .[ly].o rules and builds the
.o's again from the wrong sources.

The intermediate .c files should probably be left alone.  This may be
easier now that they have unique names (I think the main difficulty is
getting the same .c used for all types of objects).  This would also
fix the bug that mkdep doesn't work on yacc or sources files.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605311155.VAA02361>