Date: Sat, 4 Sep 2004 23:34:23 +0300 From: Ruslan Ermilov <ru@freebsd.org> To: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> Cc: current@freebsd.org Subject: Re: M*K**BJD*RPR*F*X and make.conf Message-ID: <20040904203423.GI92176@ip.net.ua> In-Reply-To: <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK> References: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> <20040829143403.GE23120@ip.net.ua> <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 "<above>:.*/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+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040904203423.GI92176>