M*K**BJD*RPR*F*X and make.conf
Ruslan Ermilov
ru at freebsd.org
Sat Sep 4 13:34:48 PDT 2004
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:
>
> 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.
>
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'.
>
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.)
>
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.
>
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 = getenv("MAKEOBJDIRPREFIX"))) {
main.c- if (!(path = getenv("MAKEOBJDIR"))) {
main.c- path = _PATH_OBJDIR;
main.c- pathp = _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).
>
> [00:22:41]beer at NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1063}$ grep MAKEOBJ /etc/make.conf
> # MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME}
> ## Let's break the build elsewhere... MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME}
>
> [00:22:59]beer at NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1064}$ grep -v ^# /dist/build/build-freebsd-current
> MOUNT=`/sbin/mount -t union`
> UNION=`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=i386 __MAKE_CONF=`dirname $0`/../conf/current/make.conf make -DNOCLEAN buildworld )
>
> [00:23:04]beer at NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1065}$ time nice -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.
>
> [ ... ]
>
> [00:34:48]beer at NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1071}$ grep MAKEO /dist/conf/current/make.conf
> # MAKEOBJDIRPREFIX?= /usr/obj/${RELNAME}
> MAKEOBJDIRPREFIX= /dist/obj/${RELNAME}
>
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=/foo
$ make __MAKE_CONF=/usr/src/make.conf buildworld
"/usr/src/Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environment, 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.
>
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=/foo"
...
src/Makefile calls
"env MAKEOBJDIRPREFIX=/foo make -f Makefile.inc1 buildworld"
...
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=/foo"
...
src/Makefile calls
"env MAKEOBJDIRPREFIX=/foo make -f Makefile.inc1 buildworld MAKEOBJDIRPREFIX=/foo"
...
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...
>
Try with the current make(1).
> the following in Makefile which helps when I've given __MAKE_CONF:
>
> _MAKEOBJDIRPREFIX!= env -i PATH=${PATH} __MAKE_CONF=${__MAKE_CONF} \
> MAKEFLAGS="${.MAKEFLAGS}" ${MAKE} \
> -m ${.CURDIR}/share/mk -f /dev/null -V MAKEOBJDIRPREFIX dummy
>
> With this, I can no longer build:
> [03:54:13]beer at NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:/dist/src/FreeBSD6-src/
> src{1212}$ time nice env TARGET_ARCH=i386 __MAKE_CONF=/dist/conf/current/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 variable.
>
> 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.
>
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.)
>
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,
--
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040904/8ade1916/attachment.bin
More information about the freebsd-current
mailing list