Date: Tue, 14 May 2002 09:52:20 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: John Hay <jhay@icomtek.csir.co.za> Cc: current@freebsd.org Subject: Re: makefiles broken with make -j? Message-ID: <20020514065220.GD34081@sunbay.com> In-Reply-To: <200205131841.g4DIfBY51020@zibbi.icomtek.csir.co.za> References: <200205131841.g4DIfBY51020@zibbi.icomtek.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
--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".
<PS>
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.
</PS>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020514065220.GD34081>