From owner-svn-src-all@FreeBSD.ORG Sat Oct 20 10:13:49 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA20F5B1; Sat, 20 Oct 2012 10:13:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 535268FC0A; Sat, 20 Oct 2012 10:13:47 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q9KADaJI028962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Oct 2012 21:13:38 +1100 Date: Sat, 20 Oct 2012 21:13:36 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar Subject: Re: 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... In-Reply-To: <965E2363-6866-4A10-A7B1-C428B3C78925@xcllnt.net> Message-ID: <20121020205008.C1781@besplex.bde.org> References: <201210062001.q96K16Or030755@svn.freebsd.org> <20121007161440.C7605@besplex.bde.org> <81CB9A3A-4BFF-41B2-A1F9-3721A40F6260@xcllnt.net> <20121008165228.F7997@besplex.bde.org> <965E2363-6866-4A10-A7B1-C428B3C78925@xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=IbXfwhWa c=1 sm=1 a=LFdMy-NRfKoA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=Qs8lTao0p00A:10 a=XOAjjx_bbgUN_Qp3UXcA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: "svn-src-head@FreeBSD.org" , "svn-src-all@FreeBSD.org" , "src-committers@FreeBSD.org" , Bruce Evans , Simon Gerraty X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 10:13:49 -0000 On Mon, 8 Oct 2012, Marcel Moolenaar wrote: > On Oct 8, 2012, at 1:08 AM, Bruce Evans wrote: > >> On Sun, 7 Oct 2012, Marcel Moolenaar wrote: >> >>> On Oct 6, 2012, at 10:31 PM, Bruce Evans wrote: >>> >>>> On Sat, 6 Oct 2012, Marcel Moolenaar wrote: Back to the old thread. Followup to the new commit thread. >>>>> 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. Yes, but the old rule uses .ORDER to try to prevent parallel work, and you never explained why it stopped working. I think I expmained the problem in the later thread as finer-grained timestamps exposing old races more. > 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. Probably. Using temporary files seems to be messier. Bruce