From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 20:34:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8865116A4CE for ; Sat, 4 Sep 2004 20:34:48 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 579CC43D4C for ; Sat, 4 Sep 2004 20:34:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i84KYO1Y024424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 23:34:25 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i84KYNT8093908; Sat, 4 Sep 2004 23:34:23 +0300 (EEST) (envelope-from ru) Date: Sat, 4 Sep 2004 23:34:23 +0300 From: Ruslan Ermilov To: Barry Bouwsma Message-ID: <20040904203423.GI92176@ip.net.ua> References: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> <20040829143403.GE23120@ip.net.ua> <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="81JctsDUVPekGcy+" Content-Disposition: inline In-Reply-To: <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: M*K**BJD*RPR*F*X and make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 20:34:48 -0000 --81JctsDUVPekGcy+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 07:52:53PM +0200, Barry Bouwsma wrote: [...] > Un(?)fortunately, I can't easily demonstrate the failure that I > wanted to prevent. It probably happens later after other failures > in my build. However, here are some interesting observations: >=20 > My FreeBSD-4 `make -d v buildworld' in 6-CURRENT source fails, > period. > "Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environment, not= as a g > lobal (in /etc/make.conf) or command-line variable. > Drop the `-d v' and it doesn't bomb there. This is probably > not unexpected. ;-) It is better with a later `make' which > sends the debug output to stderr, not to stdout. >=20 Yes, the problem with RELENG_4 make(1) is that -dv sends its output to stdout, hence ``make -dv -V MAKEOBJDIRPREFIX'' is polluted. The make(1) in HEAD doesn't exhibit this problem. > The above test also does not fail when MAKEOBJDIRPREFIX is > given as command-line variable, using FreeBSD-4 `make'. >=20 Yes, because in 4.x, make(1) doesn't pass command-line variables as command-line variables to subprocesses, including other make's. > (I mean, I don't get the above warning, giving command-line > variable, and it continues with the build.) >=20 You won't get a warning with the 4.x version of make(1), because it's buggy. In 5.x and 6.x, you'll get it. I couldn't find a way to make it work with 4.x version of make(1), and setting MAKEOBJDIRPREFIX as a command line variable using the 4.x make(1), and running buildworld seems to work due to this bug in make(1) -- what happens is that the *actual* make(1) (the one that src/Makefile calls with the -f Makefile.inc1 argument) sees the MAKEOBJDIRPREFIX as an environment variable, which is what the make(1) expects. This explains why it happened to work for many people who passed it as a command-line variable before make(1) was fixed. > Anyway, what I try to demonstrate is setting MAKEOBJDIRPREFIX > in __MAKE_CONF. >=20 This is pointless. MAKEOBJDIRPREFIX is an environment variable, here's the code from make(1): $ grep -C3 MAKEOBJDIRPREFIX *.c main.c- * The object directory location is determined using the main.c- * following order of preference: main.c- * main.c: * 1. MAKEOBJDIRPREFIX`cwd` main.c- * 2. MAKEOBJDIR main.c- * 3. _PATH_OBJDIR.${MACHINE} main.c- * 4. _PATH_OBJDIR -- main.c- * and modify the paths for the Makefiles apropriately. The main.c- * current directory is also placed as a variable for make scripts. main.c- */ main.c: if (!(pathp =3D getenv("MAKEOBJDIRPREFIX"))) { main.c- if (!(path =3D getenv("MAKEOBJDIR"))) { main.c- path =3D _PATH_OBJDIR; main.c- pathp =3D _PATH_OBJDIRPREFIX; > This avoids the check in the -current Makefile > and in releng_5 Makefile.inc (which was the reason for my > previous patch-like thing). >=20 > [00:22:41]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1063}$ grep MAK= EOBJ /etc/make.conf > # MAKEOBJDIRPREFIX?=3D /usr/obj/${RELNAME} > ## Let's break the build elsewhere... MAKEOBJDIRPREFIX?=3D /usr/ob= j/${RELNAME} >=20 > [00:22:59]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1064}$ grep -v = ^# /dist/build/build-freebsd-current > MOUNT=3D`/sbin/mount -t union` > UNION=3D`echo $MOUNT | /usr/bin/egrep ":.*/src/FreeBSD6-src/source= -hacks on .*/src/FreeBSD6-src/src \(union,"` > if [ $? -ne 0 ] ; then > echo > echo "Must union-mount source-hacks before building..." > echo > exit 68 > fi > ( cd `dirname $0`/../src/FreeBSD6-src/src && time env TARGET_ARCH= =3Di386 __MAKE_CONF=3D`dirname $0`/../conf/current/make.conf make -DNOCL= EAN buildworld ) >=20 > [00:23:04]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1065}$ time nic= e -20 sh !$ > -------------------------------------------------------------- > >>> Building an up-to-date make(1) > -------------------------------------------------------------- > mkdir: /usr/obj/dist: Read-only file system > *** Error code 1 > Stop in /dist/src/FreeBSD6-src/src/usr.bin/make. >=20 > [ ... ] >=20 > [00:34:48]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1071}$ grep MAK= EO /dist/conf/current/make.conf > # MAKEOBJDIRPREFIX?=3D /usr/obj/${RELNAME} > MAKEOBJDIRPREFIX=3D /dist/obj/${RELNAME} >=20 This happens with 4.x make(1) because buildworld depends on a new make binary, and this new make binary cannot be built (due to MAKEOBJDIRPREFIX hardcoded by setting it as a global variable in a file pointed to by __MAKE_CONF. If you try it with 5.x make(1), it will fail as expected, later: $ grep MAKEOBJDIRPREFIX /etc/make.conf /usr/src/make.conf /usr/src/make.conf:MAKEOBJDIRPREFIX=3D/foo $ make __MAKE_CONF=3D/usr/src/make.conf buildworld "/usr/src/Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environme= nt, not as a global (in /etc/make.conf) or command-line variable. > Ah, well. If I specify a MAKEOBJDIRPREFIX on the command-line, > it also passes by the test. YES I KNOW I'M NOT SUPPOSED TO DO > THIS. Just like I'm not supposed to do the above. I'm deliberately > avoiding setting the environment, for the sake of science. >=20 With 4.x make(1), yes. Like has been said already, it doesn't pass command-line variables as command-line variables to subprocesses, only passes them as environment variables -- and that's what real make(1) expects -- it find the MAKEOBJDIRPREFIX as an environment variable. Here's the picture for the old make: "make buildworld MAKEOBJDIRPREFIX=3D/foo" =2E.. src/Makefile calls "env MAKEOBJDIRPREFIX=3D/foo make -f Makefile.inc1 buildworld" =2E.. Makefile.inc1 then redefines the environment variable MAKEOBJDIRPREFIX as necessary, for difference stages of buildworld. For the current make(1), the picture is as follows: "make buildworld MAKEOBJDIRPREFIX=3D/foo" =2E.. src/Makefile calls "env MAKEOBJDIRPREFIX=3D/foo make -f Makefile.inc1 buildworld MAKEOBJDIRPRE= FIX=3D/foo" =2E.. Makefile.inc1 then redefines the environment variable MAKEOBJDIRPREFIX as necessary, but this doesn't take the desired effect because command-line variable overrides the environment variable. Is that clear enough now? > My point is that I don't have MAKEOBJDIRPREFIX in /etc/make.conf > but instead in __MAKE_CONF, yet the build goes ahead... >=20 Try with the current make(1). > the following in Makefile which helps when I've given __MAKE_CONF: >=20 > _MAKEOBJDIRPREFIX!=3D env -i PATH=3D${PATH} __MAKE_CONF=3D${__MAKE_CONF} \ > MAKEFLAGS=3D"${.MAKEFLAGS}" ${MAKE} \ > -m ${.CURDIR}/share/mk -f /dev/null -V MAKEOBJDIRPREFIX = dummy >=20 > With this, I can no longer build: > [03:54:13]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:/dist/src/FreeBSD= 6-src/ > src{1212}$ time nice env TARGET_ARCH=3Di386 __MAKE_CONF=3D/dist/conf/cur= rent/make. > conf make -DNOCLEAN buildworld > "Makefile", line 93: MAKEOBJDIRPREFIX /dist/obj/4.10-STABLE can only be= set in > environment, not as a global (in /etc/make.conf) or command-line variabl= e. >=20 > This is what you want. Believe me. Still, I'm not sure if it > is safe to use `-m' here, although it does work with my 4.x. >=20 No, it's unsafe. The old make(1) may be incompatible with the current contents of src/share/mk. > (Hm, is it safe to use ${MAKE} here, seeing that later in the > makefile one `make make's to build an up-to-date, probably for > the case where `make' doesn't set `${MAKE}'... Ignore me.) >=20 Yes, it's safe. ${MAKE} expands to argv[0]. When you later call /foo/bar/make, that make's ${MAKE} becomes /foo/bar/make. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --81JctsDUVPekGcy+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBOibPqRfpzJluFF4RAlIsAKCc/kxrHrIFpYnsf9Utw771NQV42gCfd+XC s0lK0iNepgCiq8hmuJUCrYE= =oNns -----END PGP SIGNATURE----- --81JctsDUVPekGcy+--