[sorry for the delay in getting this message out. Source in question is from early 30.Aug.] Hello neighbour. Can you say, Flogging a Deceased Equine? Sure, I knew you could... > > I fully understand that you hate me now. > I will hate you if, after reading these, you still disagree. ;) You are no fun, I must try harder... 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. The above test also does not fail when MAKEOBJDIRPREFIX is given as command-line variable, using FreeBSD-4 `make'. (I mean, I don't get the above warning, giving command-line variable, and it continues with the build.) Anyway, what I try to demonstrate is setting MAKEOBJDIRPREFIX in __MAKE_CONF. 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} 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. My point is that I don't have MAKEOBJDIRPREFIX in /etc/make.conf but instead in __MAKE_CONF, yet the build goes ahead... Anyway, now I have two MAKEOBJDIRPREFIXen, and the up-to-date make gets put in the command-line location, while the next step (temporary build tree) gets put in the __MAKE_CONF location. I've specified two different locations to be even more wrong and to see which gets used where ... >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/include while later, in the legacy release compatibility shims, both locations appear: >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /dist/src/FreeBSD6-src/src; MAKEOBJDIRPREFIX=/dist/obj/4.10-STABLE/dist/src/F __MAKE_CONF location ^^^^^^^^^^^^ reeBSD6-src/src/i386 INSTALL="sh /dist/src/FreeBSD6-src/src/tools/install.sh" PATH=/dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/sbin:/dist/ obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/bin:/dist/obj/4.10-STA BLE/dist/src/FreeBSD6-src/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bi n WORLDTMP=/dist/obj/4.10-STABLE/dist/src/FreeBSD6-src/src/i386 MAKEFLAGS="-m /dist/src/FreeBSD6-src/src/tools/build/mk -D NOCLEAN -m /dist/src/FreeBSD6-src/ src/share/mk" /dist/obj/crash/dist/src/FreeBSD6-src/src/make.i386/make -f Makefi commandline location ^^^^ le.inc1 DESTDIR= BOOTSTRAPPING=450000 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNO PIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS legacy ===> tools/build cd /dist/src/FreeBSD6-src/src/tools/build; /dist/obj/crash/dist/src/FreeBSD6-src /src/make.i386/make buildincludes; /dist/obj/crash/dist/src/FreeBSD6-src/src/mak e.i386/make installincludes sh /dist/src/FreeBSD6-src/src/tools/install.sh -C -o root -g wheel -m 444 langi nfo.h /dist/src/FreeBSD6-src/src/tools/build/../../include/getopt.h regex.h /dis t/obj/4.10-STABLE/legacy/usr/include ^^^^^^^^^^^^^^^^^^^^^^ this directory doesn't even exist... This is an example of what I should *NOT* be allowed to do. However, the Makefile/.inc1 check you added recently was not able to stop me from doing so... I'm guessing the FBSD-4 `make' doesn't work properly with your test when using the improper command-line form, but a later `make' would. The following test appears to bear this out: [02:55:26]beer_at_NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{845}$ env -i /dist/ob j/crash/dist/src/FreeBSD6-src/src/make.i386/make MAKEOBJDIRPREFIX=/dist/obj -f /dev/null -V MAKEOBJDIRPREFIX -d v dummy 2>&1 | grep -e '\(t/obj\|EOBJD\)' Global:.MAKEFLAGS = MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d Global:.MAKEFLAGS = MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d v Global:MFLAGS = -V MAKEOBJDIRPREFIX -d Global:MFLAGS = -V MAKEOBJDIRPREFIX -d v Applying :M to " MAKEOBJDIRPREFIX=/dist/obj -V MAKEOBJDIRPREFIX -d v" /dist/obj whilst with FBSD-4 `make': [02:55:47]beer_at_NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{846}$ env -i make MAK EOBJDIRPREFIX=/dist/obj -f /dev/null -V MAKEOBJDIRPREFIX -d v dummy | grep -e '\(t/obj\|EOBJD\)' Global:.MAKEFLAGS = -V MAKEOBJDIRPREFIX -d Global:.MAKEFLAGS = -V MAKEOBJDIRPREFIX -d v Applying :M to " -V MAKEOBJDIRPREFIX -d v" Global:MFLAGS = -V MAKEOBJDIRPREFIX -d v /dist/obj Indeed, if I invoke make as in the first instance above, I fall over your test (tested with releng-5). My /usr/share/mk has no mention of __MAKE_CONF while it's present in later RELENG_4; I suspect this is why building an up-to-date `make' failed to find the improperly-specified MAKEOBJDIRPREFIX in the __MAKE_CONF I gave. Or something. Is the fact that upgrade_checks calls ``make make'' without `-m .../mk' the reason for this? Is it dangerous to specify the newest src/share/mk at this point? I suspect it is. If so, I suspect that the -current Makefile test would also fail with my old /usr/share/mk when handed __MAKE_CONF, while that in releng_5 Makefile.inc1 would successfully stop my build, which is what I want to happen. This is the case, as _MAKE with `-m' is used with .inc1) Sorry if this isn't clear. Even I have a hard time explaining it myself. I want your test to stop me from being able to do the things I can do above, if it's possible, but I suspect that my /usr/share/mk is too old to help with -current, as is my `make'... Anyway, I don't have a solution to prevent someone from using an older `make' and passing `MAKEOBJDIRPREFIX=/foo' as a command-line variable; however, for -current, I've changed 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. (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.) thanks barry bouwsmaReceived on Sat Sep 04 2004 - 15:53:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:10 UTC