From owner-freebsd-current Mon May 13 23:53:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 3B9F137B404 for ; Mon, 13 May 2002 23:53:20 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g4E6qKC41108; Tue, 14 May 2002 09:52:20 +0300 (EEST) (envelope-from ru) Date: Tue, 14 May 2002 09:52:20 +0300 From: Ruslan Ermilov To: John Hay Cc: current@freebsd.org Subject: Re: makefiles broken with make -j? Message-ID: <20020514065220.GD34081@sunbay.com> References: <200205131841.g4DIfBY51020@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t" Content-Disposition: inline In-Reply-To: <200205131841.g4DIfBY51020@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --LKTjZJSUETSlgu2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2002 at 08:41:11PM +0200, John Hay wrote: > Hi, >=20 > It looks like the makefiles are a bit broken if make -j13 is used. What > I see here is that osreldate.h in obj/usr/src/i386/usr/include/ looks > like this: >=20 > ############################ > ... > #ifdef _KERNEL > #ifdef _KERNEL > #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/pa= ram.h" > #error "/usr/include/osreldate.h cannot be used in the kernel, use sys/pa= ram.h" > #else > #else > #undef __FreeBSD_version > #undef __FreeBSD_version > #define __FreeBSD_version 500035 > #define __FreeBSD_version 500035 > #endif > #endif > ############################ >=20 > When looking at the output of "make -j13 world", it looks like some parts > are being run more than once: >=20 > ############################ > -------------------------------------------------------------- > >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHINE=3D= i386 OBJFORM > AT_PATH=3D/usr/obj/usr/src/i386/usr/libexec PERL5LIB=3D/usr/obj/usr/src/= i386/usr/li > bdata/perl/5.6.1 GROFF_BIN_PATH=3D/usr/obj/usr/src/i386/usr/bin GROFF_F= ONT_PATH=3D > /usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=3D/usr/obj/us= r/src/i38 > 6/usr/share/tmac DESTDIR=3D/usr/obj/usr/src/i386 INSTALL=3D"sh /usr/src= /tools/inst > all.sh" PATH=3D/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/= bin:/usr/ > obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile= .inc1 S > HARED=3Dsymlinks includes incsinstall > =3D=3D=3D> share/info > =3D=3D=3D> share/info > =3D=3D=3D> include > =3D=3D=3D> include > Setting up symlinks to kernel source tree... > ############################ >=20 I also see the breakage with -j8 "make release", but in a different place, while building "krb5" dist. I'm currently testing this patch. %%% Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.273 diff -u -r1.273 Makefile.inc1 --- Makefile.inc1 12 May 2002 16:00:43 -0000 1.273 +++ Makefile.inc1 14 May 2002 06:32:01 -0000 @@ -299,7 +299,7 @@ @echo "--------------------------------------------------------------" @echo ">>> stage 4: populating ${WORLDTMP}/usr/include" @echo "--------------------------------------------------------------" - cd ${.CURDIR}; ${WMAKE} SHARED=3Dsymlinks includes incsinstall + cd ${.CURDIR}; ${WMAKE} includes; ${WMAKE} SHARED=3Dsymlinks incsinstall _libraries: @echo @echo "--------------------------------------------------------------" %%% Now I know why running "make all install" is not a good idea (in the -j case). ``.ORDER: all install'' or ``.ORDER: includes incsinstall'' do not work because these do not cause the necessary ordering for sub-dependents. What I mean here is that: all: ${PROG} ${SCRIPTS} ${FILES} _includes _manpages install: realinstall realinstall: _proginstall _scriptsinstall _filesinstall _incsinstall _manin= stall And ``.ORDER: all install'' does not cause e.g. _includes and _incsinstall to be run in sequence. One might now wonder why not fix it like this: =2EORDER: _includes _incsinstall The answer is that makefiles are allowed to redefine "includes" and/or "incsinstall". In that case, _includes and/or _incsinstall won't even be defined, and we'd now have to make sure (in this particular makefile) that "make includes incsinstall" works in -j case by providing the necessary .ORDER'ing, while not running "making" and "installing" parts together in the -j case will "just work". Bruce, yes I am aware of the problem with _incsinstall attempting to "make" includes if they are not built. I even attempted to fix it like this: %%% =2Eif exists(${file}) _fooinstall: _fooinstall_${file} _fooinstall_${file}: ${file} ${INSTALL} ${.ALLSRC} ... =2Eendif %%% But this unfortunately breaks the common "make all install" case, which is (as should be apparent from the previous paragraph) is just wrong in the -j case. Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --LKTjZJSUETSlgu2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE84LQkUkv4P6juNwoRAunyAJ42Rqjk3TAMtx4hCSAsJV+xd+sU0wCcCP6G ZEcfiK4V3ioKnGUVICQPEYc= =6Art -----END PGP SIGNATURE----- --LKTjZJSUETSlgu2t-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message