Date: Thu, 23 Feb 2023 14:34:57 -0800 From: "Simon J. Gerraty" <sjg@juniper.net> To: Mark Millard <marklmi@yahoo.com> Cc: Bryan Drewery <bdrewery@FreeBSD.org>, Current FreeBSD <freebsd-current@FreeBSD.org>, Peter <pmc@citylink.dinoex.sub.org>, <sjg@juniper.net> Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) Message-ID: <36040.1677191697@kaos.jnpr.net> In-Reply-To: <CEABBA9E-7D06-49C0-B593-BBA30AD1C8C4@yahoo.com> References: <B74790D9-FBC2-4818-BEAF-34E5B705C460@yahoo.com> <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <DB0C7B41-2101-4C5C-BFC8-3C95CC0B9F6F@yahoo.com> <73088.1611797582@kaos.jnpr.net> <CB7040D0-3BF4-496F-A54F-87E5378016E0@yahoo.com> <F6BF110D-7855-4A10-A53F-52B34282234F@yahoo.com> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <72419.1677133429@kaos.jnpr.net> <B11DA944-90E7-42D9-81A4-145686767305@yahoo.com> <30.1677183903@kaos.jnpr.net> <CEABBA9E-7D06-49C0-B593-BBA30AD1C8C4@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Millard <marklmi@yahoo.com> wrote:
> [External Email. Be cautious of content]
> =
> =
> [Note for "how many separate bmake instances are in that log?":
> I do not know how to tell how many submakes are run total. It
> was with -j32 on the threadripper 1950X, if that is was you
> were after.]
You can get a clue from the number of directories being built - each
will have its own instance of bmake.
> > Per my last response, I'd be pretty sure MAKEOBJDIR is incorrect.
> =
> Which still leaves me experimenting to find a correct
> reference. Do you know notation will always lead to the
> same absolute path with the proper /usr/obj/BUILDs/*/usr/main-src/*.*/
> prefix ? (I've been showing just the main-amd64-nodbg-clang
> and amd64.amd64 combination but there are many more.)
I would question why you care. What is wrong with ${OBJTOP} ?
Hmm, this does not look promising actually:
grep '^OBJTOP' share/mk/*mk
share/mk/bsd.obj.mk:OBJTOP?=3D ${MAKEOBJDIR}
share/mk/bsd.obj.mk:OBJTOP?=3D ${.OBJDIR:S,${.CURDIR},,}${SRCTOP}
share/mk/local.meta.sys.mk:OBJTOP:=3D ${OBJROOT}${TARGET_OBJ_SPEC}
share/mk/local.meta.sys.mk:OBJTOP :=3D ${HOST_OBJTOP}
share/mk/local.sys.mk:OBJTOP?=3D ${.OBJDIR:S,${.CURDIR},,}${SRCTOP}
share/mk/src.sys.obj.mk:OBJTOP:=3D
${OBJROOT}${TARGET}.${TARGET_ARCH}
share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT:H}
share/mk/src.sys.obj.mk:OBJTOP:=3D
${OBJROOT}${MACHINE}.${MACHINE_ARCH}
share/mk/src.sys.obj.mk:OBJTOP:=3D ${OBJROOT:H}
share/mk/src.sys.obj.mk:OBJTOP:=3D ${MAKEOBJDIRPREFIX}${SRCTOP}
share/mk/src.sys.obj.mk:OBJTOP=3D ${SRCTOP}
Without full context, apart from local.meta.sys.mk some of the above
looks highly dubious
In some respects the BSD build provides way too much flexibility.
About 20 years ago at Juniper we found it untenable to continue allowing
users 4 different options for the relationship between their srcs and
objects. So we simply mandated:
SRCTOP=3D ${SB}/src
OBJROOT=3D ${SB}/obj/
OBJTOP=3D ${OBJROOT}/${MACHINE}/
MAKEOBJDIR=3D ${.CURDIR:S,${SRCTOP},${OBJTOP},}
and life was better, but in a project like FreeBSD you cannot imposed
your will that way ;-)
> >>>>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/
> >>>>
> >>>> (Ignoring the variability of OBJTOP issue . . .)
> >>>>
> >>>> I do not expect that would work: ignoring things
> >>>> it likely should not.
> >>>
> >>> Sure, but it may be useful as an experiment to ensure things are
> >>> behaving as expected.
> >>
> >> As a test:
> >>
> >> .if ${.MAKE.LEVEL} =3D=3D 0
> >> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIR:tA}/tmp/
> >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS}
> >> .endif
> >
> > Lose the .if ${.MAKE.LEVEL} =3D=3D 0
> > it is almost certainly keeping things from working as expected.
> =
> What do you want tested instead of MAKEOBJDIR ?
I would expect you want ${OBJTOP} (assuming a sane value for OBJTOP ;-)
> I'm taking a guess (no .MAKE.LEVEL use):
Correct.
> =
> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP:tA}/tmp/
> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS:tA}
You do not want to apply :tA to everything.
.MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ ${OBJTOP:tA}/tmp/
should be valid.
> =
> =
> >> I still get things like:
> >>
> >> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/G=
ENERIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86.meta: 23: file '/us=
r/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy/us=
r/sbin/realpath' is newer than the target...
and is OBJTOP /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am=
d64
?
> >> Building /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.am=
d64/sys/GENERIC-NODBG/modules/usr/main-src/sys/modules/zlib/x86
> >
> > Because that will not be level 0 and so .MAKE.META.IGNORE_PATHS is not
> > set.
> =
> I tried the above and I still get (picking to look for
> tmp/legacy/usr/sbin/ln examples):
> =
> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENE=
RIC-NODBG/modules/usr/main-src/sys/modules/aac/opt_scsi.h.meta: 22: file '=
/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/legacy=
/usr/sbin/ln' is newer than the target...
Its a bit messy with kernels since there isn't a src directory
associated with each (in FreeBSD anyway) but you could add the following
to one of the makefiles that will be in play:
.info ${.CURDIR .OBJDIR OBJTOP .MAKE.META.IGNORE_PATHS:L:@v@${.newline}$v=3D=
${$v}@}
to help you see what is going on.
It should then be easy to see whether OBJTOP is covered by
.MAKE.META.IGNORE_PATHS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36040.1677191697>