From nobody Tue May 6 22:35:23 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZsYBd1kz0z5vYnX for ; Tue, 06 May 2025 22:35:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZsYBc6P03z3wHW for ; Tue, 06 May 2025 22:35:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746570935; bh=o5GxFrle1npBAmXvt9ofcvVkoPZ0rXI+Of75nuMdLCU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ZCzHpF2TuuuYwwWXBrNajwJv0CkveRo9d9LQ4bwea/R31ZIbSILkF3tN+Ms8oxegXkCYv+SE9CxKUzgq2bNvsfCUah5UEFhyqmTSxMKJtEmuhnIZvyoeC7FXiIIp0HYeOlQZTBWDw6NQFlX9oCTQPey+kKvRvGCIRh5//M/Fz2CNC/fPsaPOqLka9f6yn1eygt4E0//48fYbCwbIlqBZYeADnGnE9k3dwcM5SrvNX4UYlUfiCXB2MlNzeoLp5hLzjLRmyNhNsMKeB3BXcysxN4nm/SUWC2uQvwO23+OpB2roPUoYbi+Fz/i0T4ulMwS0pQ2myZ48cxJYV8LsujZOjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1746570935; bh=66LVbs5wzkcJ6qw+DB0VhmwTn8rqAF85B6exstuw7pg=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qR+c5J4SfNkyPJe4hbo4E9icADU/9rJ9/DawvmPdDDh4N4sCoBY0SMdHfmssWcL0f5CIa80JZ74GiwdaxFHAP/m0/W3mI7pjx3BKdvEt+LdBanER9PdX2eWccgiOCPYHIpElRepeRfBgYqVxtw9y1wlEAtkIuNez6i5r+RD7GkrrLm/KQT/5hUllwKAqftE2iDaejZb0l7YGJQAy6fdjcy28VQcQ3NSoQpxMfZMNoKYn4EzODO9aVcV1wjAPHgYqA3cFpTI5lbw02RLG/DaUlfJteDqayx/CH0ASDGQQPmWsrGCJTGoBdgtsJDeMnfXbPvp4NTw84n/QSvcWvbmkVg== X-YMail-OSG: lLIrSL8VM1kBfDAUNJ_Wn83BvWNnPyg9FyIkwAAsS1RCJbvoKPMQd5yWwrKfUz9 EaI23vjKLvQSoffN9f2Y1WpzxLPAruwyHhZmKgcvbMAuKTE_1tCsdRukbBE9G9p4rri62a5XIG_2 2nZAC_7vCy0NZZosgzjfxEvP_8YgozSbCT40VtF1_rcDWip99i3K7VU7LifX3D8xs8y_gNR8tPA. sscIXOXi4Q8XxOnMzNX7VdquzUxwn6B9UaZUnIk5uZVJItKeYO2u.Zljn.bY_XLAcKhkh7YNykou JLWFsB_oUPmdTY_W6udmJavurY6uUJD.cuLAY8nXNsQaz.lDXHIi8BeIqmx9HHXceeWq7ETXAmzb Aziid3QtdxgbU9iMFChGg1PM11V1zPNCIheQB0hzeYI23ZvRXlztgLTlHuL6nrphx45zhdznGVOJ Ue.jcZV.W6OzUtRBbWgk_yMYfQepnsDv97Tl3paqMUDxYd6cm4YDtDx688uErFT2kdwFHzm.HE.E 7Z1lWQ5_53mJFBlwAnpR_m44p7NNl3mFlml8PAtBl.pp3T1E78YPfO0cnU9IHFpx3x9.3QX_MTiI couIY8ZZhzAIMmXQOB0NEqhZIECHjpQh9GB0jJWG7wRvBcSXx0XjfWOdAnTC.SS30nrIZ1V1ZVnU QXstcHMitgnkeF_iWo4_YxPqIlNZdx4H8Jw157TkFQ.kV7O42v45B6QHhqX8FVg9QgCuLf3lmpZo LLUCrhW5cqW6Q2Cco92xzavxdz6yhqsT2hgGyxi_lFRp.qpGawgPVW8osBslM0jeIOlhdAWE8QyV KS2wIBn21hlEw4vwynodPJUeW3rTevIEgsnb797AW3H1jLqQWwghuIONojaDj7oI2LQZXuO2jjPW WSZ57DWWbxpHHkxtc.K9svAXUzd6HQ3_xullSPsmZs2e6a8.YtYGdohRgWO5ogKLzjns0CzZckRU 1d2UFQ6.7fz2h2fiEKzvannDLPG2XD.eoWjexVBiJ9iLlVK5JzQ2NjS4jKNBE9eSzQru3md5cFfu 0ub4_jsR5hI.74Pfy5MiHSL2tef30uHHgDDDFjGs6SHD.9EHRV.IgBoxzQrrQtSe1uYDu.9nNeZP 3odHWt2jtdKraUwKA9Am0b8wTT2InSAur3ke8Fk.NWnRWPl_1KRiLSI6fhzffZ6L_0EJ37q.g01W P2kOyyH69BFAOtP0hrkkAB3SesTa2rS2Hws9xit484KUpGdINXo7u0vuXUCMl.HJbYGi4gxkhdoT .ghKgDgON3v0dJiz8rekhP9mDbMGNcocTneVx63oPX.nO3A7edpwrMjXh79pdCsM4EsKXaqxe3.D PM.SgCvmG0woVVZcOmKRvQAyx3EsPmkHvGMpDc9GtRcgHEiXkqbvpIfiCU5dA3FQRUaiHw51EHVh BR84bIZR9aqeZ73Nju98tnTDKmFixb0q3.B6cHmXdlYyjNMFnYKSH9Qc5HBFosVAWi1uQXE7doYs qAFFmGoYvAVMz.LlDUhHMUi0RIQVCu7a4DbnzL9e_QJ5ZcMOIt3CKj6arkBl.EqKulGJr5H.eO_3 O2I_zGKlUqzB.u.aJIV9zBn_ki76NGB9Pz58HBC1t8mdhpAQtGv4EHR_y5bssgYNQ8.D3dcjamps ANzxJzv8ZDw_zbWwZ7MrRlAvMnUvG1shV4XWHuSFlDLCjvfJnwXMndhlRXfSE1njsWCiyAl5g9wN gkGr_BLvIPIsLtz7PlKJb_UpK6W2he18_VxzjC7fCOrRYj29SwYcuhFTkXQ7_kjPpKt7BPITtdlY HxPdMnhXrSW_o3jLa2ZZOubWh86idnggOAhif5Eo3dhaL2QSDchP3_9Atw8qjzaLHyUzuwP_nQAI K0ej3z1NdTuL.XYbhn2EhwXgGh4yBKVbbD6Zdd0dKZbZDfP_At2FjSrmPo0UsAUHmufCE8mnNAW8 BCOA.OnQgnNPMFqj8r8UWkFSflu_WIZ36XVPdd75C_XhaAR8At8I3MrWnlIuDPnFUR4fxwiDuhLj zZFJLTa5R0_jzOHLSneSBcCaWAbWjVwLL13T5.3fIEPXpKUvg3mxW0sP2VEHiHWVRdqx0WJNj8mb eJVjyBTAv9qCbJwcTBUDfZ8zMdZFC7B8UGA7Yu_ZFtbXQHJFrLKn0isADhQkHawFCos3IsfSzYma M1P3Pr7Kzqb8bODJpKgJpELM.2hX22ApDTgjiEuQMfpZVHAWzrzBVCvE2ohYyV5zy8qcs.Tk3uaF HcWpjaW0N9bl6rW2aZeQ1z1QJQGSpq3QK_HuIS3STRJq0.mnqf9K6RN4mojKCy18j458AZOv7AQu _O8s1x_0- X-Sonic-MF: X-Sonic-ID: ecf3e492-a398-4579-9e73-e4d1d0dbeb7a Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 May 2025 22:35:35 +0000 Received: by hermes--production-gq1-74d64bb7d7-mh87r (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5cc5f9d1ddcd22853e876182380e9127; Tue, 06 May 2025 22:35:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: incremental bulds from scratch with beinstall.sh From: Mark Millard In-Reply-To: <87401.1746562441@kaos.jnpr.net> Date: Tue, 6 May 2025 15:35:23 -0700 Cc: Nuno Teixeira , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <4ACBBC16-3BB6-436A-B0B1-A18F088B000E@yahoo.com> References: <28F2BDE7-5903-4C04-A570-6A407F19D5F2.ref@yahoo.com> <28F2BDE7-5903-4C04-A570-6A407F19D5F2@yahoo.com> <49396.1746554966@kaos.jnpr.net> <87401.1746562441@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Rspamd-Queue-Id: 4ZsYBc6P03z3wHW X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Spamd-Bar: ---- On May 6, 2025, at 13:14, Simon J. Gerraty wrote: > Mark Millard wrote: >>> Of course trying to get too clever can end up being counter = productive, >>> but the tools are there... >>=20 >> I still have the addition that we found was needed >> in my experiments years ago (white space details >> below may not have been preserved): >=20 > IIRC there are a few problem locations in the build where this or > similar caused problems. I think this relates to some hierarchies = being > built with custom env - which makes it hard for src.sys.obj.mk to = always > get things right. >=20 > I think the change below or close to it has been committed and = reverted > in the past. Just as a reminder of how you got to the point of providing me that patch . . .=20 QUOTE (from old, 2023 Email) >> Perhaps you want to be using >>=20 >> .MAKE.META.IGNORE_PATHS+=3D ${MAKEOBJDIRPREFIX}/tmp/legacy/usr >> or is that = ${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr >>=20 >=20 > I had started with trying to use MAKEOBJDIRPREFIX but it > appeared to end up with an empty expansion in something > I'd looked at, making the addition to > .MAKE.META.IGNORE_PATHS ineffective. >=20 > But with the .info lines in place, I should probably > recheck an example with ${MAKEOBJDIRPREFIX} in it. > (Expecting .MAKE.META.IGNORE_PATHS to not work but > showing what happens for the MAKEOBJDIRPREFIX use.) > This turns out to be different for "modules" vs. > "pure kernel". I start with a "modules" example > below. Yes, if the value of MAKEOBJDIRPREFIX isn't consistent that's going to cause problems (I'd call it a bug). If so don't use MAKEOBJDIRPREFIX directly, set some other variable and export that. Hmm src.sys.obj.mk plays games with MAKEOBJDIRPREFIX so that's probably not a good option. Perhaps: diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk index 3b48fc3c5514..3c7e570dbdbd 100644 --- a/share/mk/src.sys.obj.mk +++ b/share/mk/src.sys.obj.mk @@ -67,6 +67,9 @@ SB_OBJROOT?=3D ${SB}/obj/ OBJROOT?=3D ${SB_OBJROOT} .endif OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ +# save the value before we mess with it +_OBJROOT:=3D ${OBJROOT:tA} +.export _OBJROOT .if ${OBJROOT:M*/} !=3D "" OBJROOT:=3D ${OBJROOT:H:tA}/ .else and then something like? .MAKE.META.IGNORE_PATHS +=3D ${_OBJROOT}/${MACHINE}.${MACHINE_ARCH}/tmp/legacy/usr > and still not right (MAKEOBJDIRPREFIX expanded > to empty). See above END QUOTE My understanding was that, without something new like what is named _OBJROOT here, the .MAKE.META.IGNORE_PATHS usage simply would not work reliably, just like it did not work with anything I tried before you supplied the _OBJROOT definition to use. See the more cmoplete text for how it is used that I've added later below. >> # git -C /usr/main-src/ diff share/ >> diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk >> index 708559edcdb8..e710ae057fc6 100644 >> --- a/share/mk/src.sys.obj.mk >> +++ b/share/mk/src.sys.obj.mk >> @@ -66,6 +66,9 @@ SB_OBJROOT?=3D ${SB}/obj/ >> OBJROOT?=3D ${SB_OBJROOT} >> .endif >> OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ >> +# save the value before we mess with it >> +_OBJROOT:=3D ${OBJROOT:tA} >> +.export _OBJROOT >> .if ${OBJROOT:M*/} !=3D "" >> OBJROOT:=3D ${OBJROOT:H:tA}/ >> .else >>=20 >> where I had to use _OBJROOT to have 2 appropriate paths >> built. (See later below.) >>=20 >> It is still not part of the official share/mk/src.sys.obj.mk >> so I normally avoid referencing it or what would involve >> its use. But I've not checked if it has been added via some >> other place providing the definition. >>=20 >> Used via: >>=20 >> # grep -r "\<_OBJROOT\>" ~/src.configs/ >> /root/src.configs/make.conf:# _OBJROOT is an addition to = share/mk/src.sys.obj.mk >> /root/src.configs/make.conf:# +_OBJROOT:=3D ${OBJROOT:tA} >> /root/src.configs/make.conf:# +.export _OBJROOT >> /root/src.configs/make.conf:IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr >> /root/src.configs/make.conf:IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin >>=20 >> It was associated with symbolic links begin involved. >=20 > Your use of _OBJROOT looks similar to how we (Juniper) use SB_OBJROOT. > We run make via a wrapper which defines SB (location of the tree) and = a > number of SB_* variables which can be assumed correct. It also = obviates > the need for make.conf >=20 > Of course our build is never used to "install" anything - we just = build > packages which are then installed, so it is much simpler. As for more detail on how _OBJROOT was used: QUOTE For reference, I'm using the below block of text for the .MAKE.META.IGNORE_PATHS adjustments now. # _OBJROOT is an addition to share/mk/src.sys.obj.mk # provided by Simon J. Gerraty for my experimentation # with this avoidance of some unnecessary build # activity in META MODE: # # OBJROOT?=3D ${_default_makeobjdirprefix}${SRCTOP}/ # +# save the value before we mess with it # +_OBJROOT:=3D ${OBJROOT:tA} # +.export _OBJROOT # # TARGET.TARGET_ARCH for amd64 stays as amd64.amd64 for obj-lib32 = (correct for the purpose) # MACHINE.MACHINE_ARCH for amd64 turns into i386.i386 for obj-lib32 = (wrong for the purpose) # IGNORELEGACY_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/legacy/usr IGNOREOTHER_NOSYMLINKPREFIX=3D = ${_OBJROOT}/${TARGET}.${TARGET_ARCH}/tmp/usr/bin # .for ignore_legacy_tool in awk basename cap_mkdb cat chmod cmp cp = crunchgen crunchide cut date dd dirname echo egrep env expr fgrep file2c = find gencat grep gzip head hostname jot lex lb ln ls m4 make mkcsmapper mkdir mktemp mtree mv nawk patch realpath rm sed sh sort = touch tr truncate uudecode uuencode wc xargs .MAKE.META.IGNORE_PATHS+=3D = ${IGNORELEGACY_NOSYMLINKPREFIX}/sbin/${ignore_legacy_tool} .endfor # .for ignore_other_tool in ctfconvert objcopy nm .MAKE.META.IGNORE_PATHS+=3D = ${IGNOREOTHER_NOSYMLINKPREFIX}/${ignore_other_tool} .endfor # .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com