svn commit: r241298 - in head: . gnu/usr.bin/cc/cc_int gnu/usr.bin/cc/include kerberos5 kerberos5/tools/asn1_compile kerberos5/tools/slc lib/clang/include share/mk tools/build/make_check usr.sbin/c...

[Marcel Moolenaar]

On Oct 8, 2012, at 1:08 AM, Bruce Evans <brde at optusnet.com.au> wrote:

> On Sun, 7 Oct 2012, Marcel Moolenaar wrote:
> 
>> On Oct 6, 2012, at 10:31 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>> 
>>> On Sat, 6 Oct 2012, Marcel Moolenaar wrote:
>>> 
>>>> Log:
>>>> Add support for bmake. This includes:
>>>> ....
>>>> Modified: head/share/mk/bsd.dep.mk
>>>> ==============================================================================
>>>> --- head/share/mk/bsd.dep.mk	Sat Oct  6 19:57:27 2012	(r241297)
>>>> +++ head/share/mk/bsd.dep.mk	Sat Oct  6 20:01:05 2012	(r241298)
>>>> @@ -102,8 +102,8 @@ ${_YC} y.tab.h: ${_YSRC}
>>>> CLEANFILES+= y.tab.c y.tab.h
>>>> .elif !empty(YFLAGS:M-d)
>>>> .for _YH in ${_YC:R}.h
>>>> -.ORDER: ${_YC} ${_YH}
>>>> -${_YC} ${_YH}: ${_YSRC}
>>>> +${_YH}: ${_YC}
>>>> +${_YC}: ${_YSRC}
>>>> 	${YACC} ${YFLAGS} -o ${_YC} ${.ALLSRC}
>>>> SRCS+=	${_YH}
>>>> CLEANFILES+= ${_YH}
>>> 
>>> This is broken.  Yacc headers don't depend on generated yacc .c files.
>>> Now there is only a null rule to create the headers.  One broken case
>>> is when the header somehow gets deleted.  It bcomes out of date, but
>>> running make to update it only runs the null rule, so it remains
>>> nonexistent.
>> 
>> The problem with the old rule is that it's broken as well. The
>> change attempts to fix a real parallel build problem. Your
>> comment is valid though. What about the following (possibly
>> white-space corrupted) patch from Simon:
> 
> What's wrong with the old rule?  It uses the .ORDER directive to force
> creation of the 2 generated files in sequential order, so that parallel
> builds can't happen.

Since the source file is re-created when the header is created,
any parallel work done with the C file is a problem.

At HP, where we used clearcase & clearmake, we had to create
an intermediate tarfile, the result of the yacc(1) rule and
then have the .h and .c file depend on the tarfile. Each got
unique created by extracting only ${.TARGET}.

Roughly and loosely speaking:

.tar: .y
	yacc and create tar file

.c: .tar
	tar x y.tab.c

.h: .tar
	tar x y.tab.h

I think something like this is the only way to get something
that's 100% correct.

-- 
Marcel Moolenaar
marcel at xcllnt.net