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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:10 UTC