From owner-svn-src-all@FreeBSD.ORG Sat Oct 20 18:24:23 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 810BF16C; Sat, 20 Oct 2012 18:24:23 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC3A8FC12; Sat, 20 Oct 2012 18:24:16 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUILsT02uGc9YTnr38S64+MMMI8V0eluq@postini.com; Sat, 20 Oct 2012 11:24:23 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 20 Oct 2012 11:18:23 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q9KIIMh90987; Sat, 20 Oct 2012 11:18:22 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id A6C6C58094; Sat, 20 Oct 2012 11:18:22 -0700 (PDT) To: Bruce Evans 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: <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> <20121020205008.C1781@besplex.bde.org> Comments: In-reply-to: Bruce Evans message dated "Sat, 20 Oct 2012 21:13:36 +1100." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Sat, 20 Oct 2012 11:18:22 -0700 Message-ID: <20121020181822.A6C6C58094@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: "svn-src-head@FreeBSD.org" , "svn-src-all@FreeBSD.org" , Marcel Moolenaar , "src-committers@FreeBSD.org" , sjg@juniper.net 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 18:24:23 -0000 On Sat, 20 Oct 2012 21:13:36 +1100 (EST), Bruce Evans writes: >Back to the old thread. Followup to the new commit thread. I seem to have missed a bit of the conversation, so sorry if some of this has been done to death already. First some background: I believe the reason for the original change (which was wrong btw, I had stared at that diff many times and saw it as what I expected it to be - which I think Marcel has now committed), is that .ORDER does not work in jobs mode in the presence of explicit dependencies (see below). Since we auto collect dependencies during the build, we've learned to avoid .ORDER, it is often responsible for introducing cycles in the dependency graph. Given the makefile: --------------------8<-------------------- .MAIN: all ALPHA=a b c d e f g h i j k l m n o p q r s t u v w x y z SECS?=1 ${ALPHA}: @echo "`date +%s` $@..."; sleep ${SECS} .NOPATH: ${ALPHA} .PHONY: ${ALPHA} ALL=r a l p h i s g i t .ifdef ORDER x!= echo .ORDER: r a l p h >&2; echo .ORDER: r a l p h .endif all: ${ALL} .ifdef DEPS_A x!= echo a: p e >&2; echo a: p e .endif --------------------8<-------------------- The following is using FreeBSD make from 10.x (though it doesn't make any difference): First compat mode: $ fmake -r -f /home/sjg/make-tests/order 1350755164 r... 1350755165 a... 1350755166 l... 1350755168 p... 1350755169 h... 1350755170 i... 1350755171 s... 1350755172 g... 1350755173 t... $ Looks as you would expect, as does jobs mode: $ fmake -r -f /home/sjg/make-tests/order -j3 1350755240 r... 1350755240 l... 1350755240 a... 1350755241 p... 1350755241 h... 1350755241 i... 1350755242 s... 1350755242 g... 1350755242 t... $ Ie. the order is no longer as listed, but we haven't introduce .ORDER yet. When we throw .ORDER in: $ fmake -r -f /home/sjg/make-tests/order -j3 -DORDER .ORDER: r a l p h 1350755270 s... 1350755270 i... 1350755270 r... 1350755271 g... 1350755271 t... 1350755271 a... 1350755272 l... 1350755273 p... 1350755275 h... $ This is again what we should expect, the order is not as listed but the sequence r a l p h is correctly ordered. However, as soon as we thrown in an explicit dependency - not even one that would conflict: $ fmake -r -f /home/sjg/make-tests/order -j3 -DORDER -DDEPS_A .ORDER: r a l p h a: p e 1350755349 r... 1350755350 i... 1350755350 s... 1350755351 g... 1350755351 t... 1350755351 e... $ That is simply incorrect. Even if we go back to compat mode: $ fmake -r -f /home/sjg/make-tests/order -DORDER -DDEPS_A .ORDER: r a l p h a: p e 1350755881 r... 1350755882 p... 1350755883 e... 1350755884 a... 1350755885 l... 1350755887 h... 1350755888 i... 1350755889 s... 1350755890 g... 1350755891 t... $ This is not correct either, but you can see that the dependency takes precedence over .ORDER. The results with bmake are more spectaclular since it detects that it is lost a spews its complaints: $ bmake -r -f /home/sjg/make-tests/order -DORDER -DDEPS_A -j3 .ORDER: r a l p h a: p e --- r --- 1350756420 r... `p' was not built (made 1, flags 2009, type b030001)! `p' has .ORDER dependency against l (made 0, flags 9, type b030001) `e' was not built (made 0, flags 2009, type b030001)! `l' was not built (made 0, flags 2009, type b030001)! `l' has .ORDER dependency against a (made 1, flags 3019, type b030001) `h' was not built (made 0, flags 2009, type b030001)! `h' has .ORDER dependency against p (made 1, flags 2009, type b030001) `i' was not built (made 0, flags 2009, type b030001)! `s' was not built (made 0, flags 2009, type b030001)! `g' was not built (made 0, flags 2009, type b030001)! `t' was not built (made 0, flags 2009, type b030001)! $ This is actually handy since you can check build logs for that sort of thing and know you have an issue. The current logic does (for the interesting case - assuming yacc -d etc) parser.h: parser.y yacc etc parser.c: parser.h touch ${.TARGET} the only downside of this, is that if parser.c is removed but parser.h is left alone, and empty parser.c will be produced. This is actually a safe failure mode (build will fail), for what is essentially a corner case. In all other respects the above is preferable because it works reliably in jobs mode and it avoids any risk of running yacc multiple times to do the same thing, and will not conflict with any auto collected dependencies (assuming parser.c includes parser.h) --sjg