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...

[Bruce Evans]

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.

> Index: share/mk/bsd.dep.mk
> ===================================================================
> --- share/mk/bsd.dep.mk	(revision 241871)
> +++ share/mk/bsd.dep.mk	(working copy)
> @@ -95,16 +95,17 @@ CLEANFILES+= ${_LC}
> SRCS:=	${SRCS:S/${_YSRC}/${_YC}/}
> CLEANFILES+= ${_YC}
> .if !empty(YFLAGS:M-d) && !empty(SRCS:My.tab.h)
> -.ORDER: ${_YC} y.tab.h
> -${_YC} y.tab.h: ${_YSRC}
> +y.tab.h: ${_YSRC}
> 	${YACC} ${YFLAGS} ${.ALLSRC}
> +${_YC}: y.tab.h
> 	cp y.tab.c ${_YC}
> CLEANFILES+= y.tab.c y.tab.h
> .elif !empty(YFLAGS:M-d)
> .for _YH in ${_YC:R}.h
> -${_YH}: ${_YC}
> -${_YC}: ${_YSRC}
> +${_YH}: ${_YSRC}
> 	${YACC} ${YFLAGS} -o ${_YC} ${.ALLSRC}
> +${_YC}: ${_YH}
> +	@touch ${.TARGET}
> SRCS+=	${_YH}
> CLEANFILES+= ${_YH}
> .endfor
>
> This makes sure the C file is always more recent than the H
> file and important to keep make happy in all situations. It
> doesn't fix the the problem of removing the C file entirely.
> At least the C file is recreated, but not with the right
> contents.

I don't like it much.

With better yacc(1) options, we could run separate yacc commands to
create each file, but that requires 2 commands in all cases so it is
not more efficient than a working .ORDER.  It could avoid the separate
cp command.  Hmm, is that command the only actual problem?  The
dependencies and ordering are incomplete for the intermediate file
y.tab.c, so it might be clobbered before it is copied.  This case is
just compatibility cruft for sources that don't name the yacc header
sensibily, but use the bad old default name y.tab.h even if they don't
use y.tab.c directly.  Such sources are still too common.

I see many ways to make the cp step more robust, so this is easy to
fix if it is the problem.  A mv instead of a cp would be more robust,
but is intentionally not used, since the y.tab.c has self references
which are used by at least (gdb) debugging.  y.tab.c is kept so that
these references are to an existent file (just not the actual source
file).

Bruce