From a a Tue Feb 19 16:21:41 2013 From: a a (a a) Date: Tue, 19 Feb 2013 08:21:41 -0800 (PST) Subject: [OpenAFS-devel] a a Message-ID: <1361290901.46153.YahooMailNeo@web164504.mail.gq1.yahoo.com> --11193365-320038201-1361290901=:46153 Content-Type: text/plain; charset=us-ascii  http://www.conamorebromley.co.uk/xzipy/91c/ti6j?03y98c7j9 --11193365-320038201-1361290901=:46153 Content-Type: text/html; charset=us-ascii

 http://www.conamorebromley.co.uk/xzipy/91c/ti6j?03y98c7j9
--11193365-320038201-1361290901=:46153-- From kaduk@MIT.EDU Wed Feb 20 00:10:21 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Tue, 19 Feb 2013 19:10:21 -0500 (EST) Subject: [OpenAFS-devel] avoiding make rules with multiple targets Message-ID: We've had a few commits over the years to help parallel builds along by splitting rules with two targets into two separate rules, one a pure dependency and the other with the actual contents of the rule (usually compile_et). A typical example is 147aeeb6c59b5f4a9f8a795a91e0c42ecf80278c (gerrit/257) (trimmed): -budb_errs.c budb_client.h: budb_errs.et budb_client.p.h +budb_client.h: budb_errs.c + +budb_errs.c: budb_errs.et budb_client.p.h $(RM) -f budb_client.h budb_errs.c; ${COMPILE_ET} -p ${srcdir} budb_errs -h budb_client However, these changes seem to cause problems for FreeBSD make, even for serial builds. The build log shows a failure to install budb_client.h , No such file or directory, but then continues on to compile linktest before bailing out (sorry for the poorly wrapped copy/paste): install -o root -g wheel -m 444 JUAFS/libjuafs.a /usr/ports/net/openafs/work/openafs-1.6.2/lib/libjuafs.a install -o root -g wheel -m 444 UAFS/libuafs.a /usr/ports/net/openafs/work/openafs-1.6.2/lib/libuafs.a case amd64_fbsd_91 in alpha_dux*|sgi_*|sun4x_*|sunx86_*|rs_aix*|*linux*|hp_ux11*|ia64_hpux*|*_darwin_1*|*nbsd*|*obsd*|*fbsd*) cd src && cd shlibafsauthent && make all ;; *) echo Not building shared libafsauthent for amd64_fbsd_91 ;; esac install -o root -g wheel -m 444 budb_client.h /usr/ports/net/openafs/work/openafs-1.6.2/include/afs/budb_client.h install: budb_client.h: No such file or directory *** [/usr/ports/net/openafs/work/openafs-1.6.2/include/afs/budb_client.h] Error code 71 cc -g -O -I/usr/ports/net/openafs/work/openafs-1.6.2/src/config -I/usr/ports/net/openafs/work/openafs-1.6.2/include -I. -I. -O2 -pipe -fPIC -c budb_errs.c [ yes != "" ] || case amd64_fbsd_91 in alpha_dux*|sgi_*|sun*_5*|rs_aix*|*linux*|hp_ux11*|ia64_hpux*|*[nof]bsd*) cd src && cd tptserver && make all ;; *_darwin_[1-6][0-9]) echo Not building MT ptserver for amd64_fbsd_91 ;; *_darwin_*) cd src && cd tptserver && make all ;; *) echo Not building MT ptserver for amd64_fbsd_91 ;; esac The make debugging output is not immediately enlightening, but provides some hints. budb_server (???) depends on ${TOP_INCDIR}/afs/budb_client.h depends on budb_client.h depends on budb_errs.c depends on budb_errs.et. Yet budb_errs.c has been generated from the rule for budb_errs.h (${COMPILE_ET} -p ${srcdir} budb_errs) and is up-to-date, so make's internal bookkeeping sees the empty rule to make budb_client.h from budb_errs.c, claims succes (I don't see this in the debugging log, though?!) and tries to install the header. The problem seems to stem from there being two calls to compile_et using budb_errs.et, one of which makes budb_errs.h and the other which makes budb_client.h. Swapping the order in which the multiple targets are split out, so that budb_errs.c depends on budb_client.h which is made via compile_et, lets my build finish here, but it's probably not the best solution. Is there reason to not make a budb_client.h that is the contents of budb_client.p.h with #include added? Alternately we could process the template manually with the shell. [tbudb has the same issue] -Ben From mmeffie@sinenomine.net Wed Feb 20 16:33:57 2013 From: mmeffie@sinenomine.net (Michael Meffie) Date: Wed, 20 Feb 2013 11:33:57 -0500 Subject: [OpenAFS-devel] avoiding make rules with multiple targets In-Reply-To: References: Message-ID: <20130220113357.9d06cd4d.mmeffie@sinenomine.net> On Tue, 19 Feb 2013 19:10:21 -0500 Benjamin Kaduk wrote: > We've had a few commits over the years to help parallel builds along by > splitting rules with two targets into two separate rules, one a pure > dependency and the other with the actual contents of the rule (usually > compile_et). > > A typical example is 147aeeb6c59b5f4a9f8a795a91e0c42ecf80278c > (gerrit/257) (trimmed): > -budb_errs.c budb_client.h: budb_errs.et budb_client.p.h > +budb_client.h: budb_errs.c > + > +budb_errs.c: budb_errs.et budb_client.p.h > $(RM) -f budb_client.h budb_errs.c; ${COMPILE_ET} -p ${srcdir} budb_errs -h budb_client > > However, these changes seem to cause problems for FreeBSD make, even for > serial builds. The build log shows a failure to install budb_client.h , > No such file or directory, but then continues on to compile linktest > before bailing out (sorry for the poorly wrapped copy/paste): This can be a problem in linux as well, using gnu/make, and is not limited to bu*. > The problem seems to stem from there being two calls to compile_et using > budb_errs.et, one of which makes budb_errs.h and the other which makes > budb_client.h. Swapping the order in which the multiple targets are split > out, so that budb_errs.c depends on budb_client.h which is made via > compile_et, lets my build finish here, but it's probably not the best > solution. > > Is there reason to not make a budb_client.h that is the contents of > budb_client.p.h with #include added? Alternately we could > process the template manually with the shell. I had started making some changes to compile_et, so I could change the depencencies in the makefiles, and posted that as gerrit 7921. But I'm worried that approach would not work if people used a different compile_et. -- Michael Meffie From marc.c.dionne@gmail.com Wed Feb 20 16:39:40 2013 From: marc.c.dionne@gmail.com (Marc Dionne) Date: Wed, 20 Feb 2013 11:39:40 -0500 Subject: [OpenAFS-devel] avoiding make rules with multiple targets In-Reply-To: References: Message-ID: --f46d04389349cd192204d62a9a29 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 19, 2013 at 7:10 PM, Benjamin Kaduk wrote: > We've had a few commits over the years to help parallel builds along by > splitting rules with two targets into two separate rules, one a pure > dependency and the other with the actual contents of the rule (usually > compile_et). > > A typical example is 147aeeb6c59b5f4a9f8a795a91e0c4**2ecf80278c > (gerrit/257) (trimmed): > -budb_errs.c budb_client.h: budb_errs.et budb_client.p.h > +budb_client.h: budb_errs.c > + > +budb_errs.c: budb_errs.et budb_client.p.h > $(RM) -f budb_client.h budb_errs.c; ${COMPILE_ET} -p ${srcdir} > budb_errs -h budb_client > > However, these changes seem to cause problems for FreeBSD make, even for > serial builds. The build log shows a failure to install budb_client.h , No > such file or directory, but then continues on to compile linktest before > bailing out (sorry for the poorly wrapped copy/paste): > > install -o root -g wheel -m 444 JUAFS/libjuafs.a > /usr/ports/net/openafs/work/**openafs-1.6.2/lib/libjuafs.a > install -o root -g wheel -m 444 UAFS/libuafs.a > /usr/ports/net/openafs/work/**openafs-1.6.2/lib/libuafs.a > case amd64_fbsd_91 in alpha_dux*|sgi_*|sun4x_*|** > sunx86_*|rs_aix*|*linux*|hp_**ux11*|ia64_hpux*|*_darwin_1*|***nbsd*|*obsd*|*fbsd*) > cd src && cd shlibafsauthent && make all ;; *) echo Not building shared > libafsauthent for amd64_fbsd_91 ;; esac > install -o root -g wheel -m 444 budb_client.h /usr/ports/net/openafs/work/ > **openafs-1.6.2/include/afs/**budb_client.h > install: budb_client.h: No such file or directory > *** [/usr/ports/net/openafs/work/**openafs-1.6.2/include/afs/**budb_client.h] > Error code 71 > cc -g -O -I/usr/ports/net/openafs/work/**openafs-1.6.2/src/config > -I/usr/ports/net/openafs/work/**openafs-1.6.2/include -I. -I. -O2 -pipe > -fPIC -c budb_errs.c > [ yes != "" ] || case amd64_fbsd_91 in alpha_dux*|sgi_*|sun*_5*|rs_** > aix*|*linux*|hp_ux11*|ia64_**hpux*|*[nof]bsd*) cd src && cd tptserver && > make all ;; *_darwin_[1-6][0-9]) echo Not building MT ptserver for > amd64_fbsd_91 ;; *_darwin_*) cd src && cd tptserver && make all ;; *) > echo Not building MT ptserver for amd64_fbsd_91 ;; esac > > > > The make debugging output is not immediately enlightening, but provides > some hints. > > budb_server (???) depends on ${TOP_INCDIR}/afs/budb_client.**h depends on > budb_client.h depends on budb_errs.c depends on budb_errs.et. Yet > budb_errs.c has been generated from the rule for budb_errs.h (${COMPILE_ET} > -p ${srcdir} budb_errs) and is up-to-date, so make's internal bookkeeping > sees the empty rule to make budb_client.h from budb_errs.c, claims succes > (I don't see this in the debugging log, though?!) and tries to install the > header. > > The problem seems to stem from there being two calls to compile_et using > budb_errs.et, one of which makes budb_errs.h and the other which makes > budb_client.h. Swapping the order in which the multiple targets are split > out, so that budb_errs.c depends on budb_client.h which is made via > compile_et, lets my build finish here, but it's probably not the best > solution. > > Is there reason to not make a budb_client.h that is the contents of > budb_client.p.h with #include added? Alternately we could > process the template manually with the shell. > > [tbudb has the same issue] > > -Ben > Sounds like we want commit 0d0b5048a5b68d4079b13609775f9234183d1947 from master? Marc --f46d04389349cd192204d62a9a29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 19, 2013 at 7:10 PM, Benjamin Kaduk = <ka= duk@mit.edu> wrote:
We've had a few commits over the years to help parallel builds along by= splitting rules with two targets into two separate rules, one a pure depen= dency and the other with the actual contents of the rule (usually compile_e= t).

A typical example is 147aeeb6c59b5f4a9f8a795a91e0c42ecf80278c (gerri= t/257) (trimmed):
-budb_errs.c budb_client.h: budb_errs.et budb_client.p.h
+budb_client.h: budb_errs.c
+
+budb_errs.c: budb_errs.e= t budb_client.p.h
=A0 =A0 =A0 =A0 $(RM) -f budb_client.h budb_errs.c; ${COMPILE_ET} -p ${srcd= ir} budb_errs -h budb_client

However, these changes seem to cause problems for FreeBSD make, even for se= rial builds. =A0The build log shows a failure to install budb_client.h , No= such file or directory, but then continues on to compile linktest before b= ailing out (sorry for the poorly wrapped copy/paste):

install =A0-o root -g wheel -m 444 JUAFS/libjuafs.a /usr/ports/net/openafs/= work/openafs-1.6.2/lib/libjuafs.a
install =A0-o root -g wheel -m 444 UAFS/libuafs.a /usr/ports/net/openafs/wo= rk/openafs-1.6.2/lib/libuafs.a
case amd64_fbsd_91 in alpha_dux*|sgi_*|sun4x_*|sunx86_*|rs_aix*|*lin= ux*|hp_ux11*|ia64_hpux*|*_darwin_1*|*nbsd*|*obsd*|*fbsd*) cd = src && cd shlibafsauthent && make all ;; =A0*) =A0echo Not = building shared libafsauthent for amd64_fbsd_91 ;; =A0esac
install =A0-o root -g wheel -m 444 budb_client.h /usr/ports/net/openafs/wor= k/openafs-1.6.2/include/afs/budb_client.h
install: budb_client.h: No such file or directory
*** [/usr/ports/net/openafs/work/openafs-1.6.2/include/afs/bu= db_client.h] Error code 71
cc -g -O -I/usr/ports/net/openafs/work/openafs-1.6.2/src/config -I/u= sr/ports/net/openafs/work/openafs-1.6.2/include -I. -I. =A0-O2 -pipe= -fPIC =A0 -c budb_errs.c
[ yes !=3D "" ] || case amd64_fbsd_91 in alpha_dux*|sgi_*|sun*_5*= |rs_aix*|*linux*|hp_ux11*|ia64_hpux*|*[nof]bsd*) cd src &= & cd tptserver && make all ;; =A0*_darwin_[1-6][0-9]) =A0echo N= ot building MT ptserver for amd64_fbsd_91 ;; =A0*_darwin_*) =A0cd src &= & cd tptserver =A0&& make all ;; =A0*) =A0echo Not building MT = ptserver for amd64_fbsd_91 ;; =A0esac



The make debugging output is not immediately enlightening, but provides som= e hints.

budb_server (???) depends on ${TOP_INCDIR}/afs/budb_client.h depends= on budb_client.h depends on budb_errs.c depends on budb_errs.et. Yet budb_errs.c has been gener= ated from the rule for budb_errs.h (${COMPILE_ET} -p ${srcdir} budb_errs) a= nd is up-to-date, so make's internal bookkeeping sees the empty rule to= make budb_client.h from budb_errs.c, claims succes (I don't see this i= n the debugging log, though?!) and tries to install the header.

The problem seems to stem from there being two calls to compile_et using budb_errs.et, one of wh= ich makes budb_errs.h and the other which makes budb_client.h. =A0Swapping = the order in which the multiple targets are split out, so that budb_errs.c = depends on budb_client.h which is made via compile_et, lets my build finish= here, but it's probably not the best solution.

Is there reason to not make a budb_client.h that is the contents of budb_cl= ient.p.h with #include <budb_errs.h> added? =A0Alternately we could p= rocess the template manually with the shell.

[tbudb has the same issue]

-Ben

Sounds like we want commit 0d0b5048a5b68d407= 9b13609775f9234183d1947 from master?

Marc
--f46d04389349cd192204d62a9a29-- From kaduk@MIT.EDU Wed Feb 20 18:23:19 2013 From: kaduk@MIT.EDU (Benjamin Kaduk) Date: Wed, 20 Feb 2013 13:23:19 -0500 (EST) Subject: [OpenAFS-devel] avoiding make rules with multiple targets In-Reply-To: References: Message-ID: On Wed, 20 Feb 2013, Marc Dionne wrote: > On Tue, Feb 19, 2013 at 7:10 PM, Benjamin Kaduk wrote: > >> We've had a few commits over the years to help parallel builds along by >> splitting rules with two targets into two separate rules, one a pure >> dependency and the other with the actual contents of the rule (usually >> compile_et). >> >> Is there reason to not make a budb_client.h that is the contents of >> budb_client.p.h with #include added? Alternately we could >> process the template manually with the shell. >> >> [tbudb has the same issue] >> >> -Ben >> > > Sounds like we want commit 0d0b5048a5b68d4079b13609775f9234183d1947 from > master? Hmm, I missed that when skimming through the logs. Yes, I think we should cherry-pick that. Simon, you want to do so, or should I? I am not fully confident that I understand the behavior of make in the case I have logs for, and thus I am not sure whether a broader issue remains. -Ben