From nobody Thu Feb 23 21:12:35 2023 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 4PN5Ml575gz3smF0 for ; Thu, 23 Feb 2023 21:12:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.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 4PN5Ml2RKlz3Gn7 for ; Thu, 23 Feb 2023 21:12:51 +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=1677186769; bh=sjEkVgQG63dRERCQMSgIOzCHYNfkIZaOGQsPrrxD9eE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CPf31CZB0Kvl52korTNWY/K9irn1HUbUZkIcWBtAQM2BvIRVc2PXTBcGgMi6oZnVAc1Kwt41S2DSqkQgozijJAOBXx7nBM58IH/hN7tykQhhdG6VVosDikLOnXIdbsgabmSZKyIDGM3v318AFLvtmRUBO7lxWQjF2jtM1l8UUMQ4/KsZyg/nZNMlBvdQta6hqjx5rQoio0YU4++Qu2XbOMI0TTeAHhNZ2SmUtdmq0Y+BUqnDDGBmkX7lKH14KjwFvbFQRh7j82IAi41Zk6kjUAcHQxRTGxCpJy7Y06t6/ehZ4OsPGPSNtaShlL2oi5PqFfD8FToSUeLm4IN5UY44Yw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677186769; bh=qTZf5RBvIxXXYIygNV9/A/39jzU1EPTV6ed85dUkjaM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=e+5UrcH3oR6aGKNgADZcvvSRcVNihqfhYjtTz2hCNe9QAkWyFbEynYDHpsOEtSNSxX39qeVLVaN1WL+nJ5jQCd3duHkCfcOLlH1BQFqJM9R9Fd+oe5B67L6YnlsXVi9fVNr1JzhBzIxdR7s/2NAyRfcmUmVD+h2enTEJIxSPrjnaWNAWhrU4BWLdppLoPxfP/ByT8zzV//mu8zGohCMQ5RrlwgPy4wSZnSgkVXkmcuJ3Qm/WbhBduYmZXtXUpJkHbQBag+lfesL7FAk5WTLhofaEBvf4LAH4nAzpbSjXfPo9M7JmC5n5mxpdFv4WkRFVOPHZ2kWqXUwdNDpQqAU8JQ== X-YMail-OSG: YnWRA30VM1mk4Im2f4V6.5xZk2R5ej4RS4WFpWVbhmgsa5LUgxVUtKm_GRb6RSb V0GqUUNI4RigOsRAbNLoXpyagRmC_HLPBcxX6tcaUU8p_ugiSE5nElqqvQLSFsPVGmwYGzm6Cigb cUc_zR7DH7dLQZqpPwBa_hoYdAGn5oon4cgIdy3HcJoo74gx.VqKfLkXe0rdrKgW.km67JLHpJA8 fv6OTx8APhzu.qw6qQ5XZ8fokANDX.dSrYg9.PYAkaUXSiVB02FrVsROwugQVX6jcssMLDMy3s_2 ki7lBIHQI_Lo6qjwZN0CDrQbYEKkjwrFKdHwFingcSsHgvsR7XboEba7gsbC.JhEJApjDQXA_PBo n4BLgOQqpak7k4_BeN7blXh5IeCMGGH79PqVsneeGAq2Fgj5F.QTTM2Nbay.KJSZhTeM5O3w7.2h WmQV1JUoEyfpdK00.eY2adXcq1GFXEnNLc6m5Ks6TIe1QXCBX0oSyjHsFp26AcFNiFNTXPcvgK_W IZBW3KWKoBR5A9AB.EaX9RFLQpO2vLlqX82ASQru.eYPs0AM0BV5WWeDugdIUg9SRo1NWPinbIDd .bl2UqzPk8aaUr6fo0zqY4d7c18jpCEbahXR4teqFOAZ_OA5HNbJ0HL_cF0Bjh02D.opYFelzdba 8drbAAKMUsjtA9QQ2YSMvTEO_qgSi7GoRlv8BGEzJd1HMfVChmUauA8FxCP.gNUF1gZJFPwcwQE7 QsRc2a3V6j5xtNRVe8xhz2LXx5HKjmZ.ZPqhDpceQ9VPVqYYc8btVTElpR_2Hu3kCnPtwDd4Wd8E 7sFTr7cUoua3riO_N0gRG0ZP8SFSIzGlgH6gN1t7Z4FyvZUMQvGfMg0epARA0cbI4Toe5OH_R.IV uxEUr6nkgOr6Zvv4CV_DwqDFaO5bWHY2vXvkvl1W8K_j_mPjwPZ6VcCXlVyMamLR6i4Bsxu7F_G9 bjqJy29akFoavbPbAwRXLu8UQ6NNTjbcAl42YUN2tlteCRR0MV3EuPgGJyD8XWSIuBRE5wW6WX34 aZ9eBITvWQPEZSY7LgxFSBVoqwsh2c3oRUxsd49OPsSdpkJyn1fLFHude9hNNuIsd70UCQwafNXz J9nFQGnTT7m.NM7Ole3_Fouxs5UAGYMsqzp1fOFVJCmZN4jp8IM1B8edu0.4YPxgP7LNw77VHbEB GQ6zwzffr8u.IrmIBQQ0xW7dbOvrm6fsDblgd9gCYB69a7.4Te2F8ZMViqYjYI_Uj1bZmwt97GYg yTMFFOJ8X14zp4ySJ1UXYOl.z2MUEd934h1H1XDd8JBn5nQtv2fq4eND68eOvEQAapNpNoas5JTd an.T16wUZQJSoQIexAiv9bUOMHZvxjqMzFfO6lnU0TmPgtrU.svUgSyNdAw0XGIkShzP6uM5GlEZ LmEOqycSdmDQWrDHDj2K.Br6lulUKbPx9kqfeqTLHpT55dqW8wKG.vFUWoeL3vRTT9SMKoOSzliu lLFT5yHX1S6RDERz0Nc3pjivPMPHcWCutEG32osGZt86Kry21OrIiTOMv60PliQG1g0ZJXOyKsuf _xMcht.mISe8.YoIS.A27G_yaTxsVIxxissYQxoc0Vfe8uiNZV8VpZPBPIsuRF7wAhWgbDGpg90L XzxV7pZWQT1QfystkJoEK5ST03.ISXmdE8PX_AJH1dVLWX9BoGVRrpXuiV33Onr96Ep1Xe2_tKLE DK7T58zUGQiUmhfJj8zWzYpqbDnlnFG_Oq5Rq5d9TxlDukKy79kXjeFb.QH5NjaB7Kb91BVv39ed OUpJw3TQKW.CghFwJiVsE2pJmuuNAuox0V5MYypxdexP9LBFew_lZ.pPpfTGueVpj_VazGfCps.h 9H7FUjx604DETanneP_85WGDltajKyF2eXRYsHZp8NujkYWQ8paYtg1t4PiKwSX5.d27O_Tn4EBi IaDR8zE_W0..x5lFMQxrRpVVvavlkSWdSgC5ZUwKYGRMHs.116_dAcGfCDPy4OSYuG7sjSZ4GCJY QHuInX3QGlsTi63is7Nl8cOKFGyGGzLLuoCJLdyvn9hX0z3Zd6v_6Xr0W5Sjis4ZwO36EjeSmQUt jPQtVJiqm7Q4da4zw9lwxSrc9yCUV_qXzzghcNFB8FHWlEc_56u.n1pcz1HIGjxmpWqvrUVF2suI MS8vqD2pCjgb.R4W5jmuJnN9uYxZ6Sw1KvKba9_RZTfhuiNRta8ZqiRwSSMLAb5SRDKpFNLAQzfg c85zVU0vAMscFX8x93fgUOtDO6EEJibPhaNCcQl2WvYE2tN_01yFZIb_YKdkP5shX40i2q5_oGQ8 7rp8UVg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 21:12:49 +0000 Received: by hermes--production-ne1-746bc6c6c4-7ksjp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e1c65c7f04acf230bc5b10be8247c77d; Thu, 23 Feb 2023 21:12:47 +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 \(3731.400.51.1.1\)) Subject: Re: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes) From: Mark Millard In-Reply-To: <42586.1677183334@kaos.jnpr.net> Date: Thu, 23 Feb 2023 13:12:35 -0800 Cc: Bryan Drewery , Current FreeBSD , Peter Content-Transfer-Encoding: quoted-printable Message-Id: References: <3345EBA5-A09C-4E3F-B94D-39F57F56BDBB@yahoo.com> <73088.1611797582@kaos.jnpr.net> <10819.1677108389@kaos.jnpr.net> <76FA98EF-6184-4D7E-A01F-0EE8117D0D10@yahoo.com> <29887.1677115125@kaos.jnpr.net> <27790339-240F-4C97-97C7-38AFD8DE03D5@yahoo.com> <7FB6F619-6E71-4075-8A6C-573564371DD5@yahoo.com> <2655.1677134606@kaos.jnpr.net> <242BB478-B2FE-4BCC-A56E-098F3FEB3EE1@yahoo.com> <42586.1677183334@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PN5Ml2RKlz3Gn7 X-Spamd-Bar: ---- 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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 23, 2023, at 12:15, Simon J. Gerraty wrote: > Mark Millard wrote: >> The contribution to the list is currently generated via >> use of: >>=20 >> .if ${.MAKE.LEVEL} =3D=3D 0 >=20 > Why is this guarded by .MAKE.LEVEL 0? > .MAKE.META.IGNORE_* should be largely irrelevant at level 0 > which in the DIRDEPS_BUILD is reserved for orchestration. > Even in the legacy build, level 0 would be just the top-level = makefiles > and anything dealing with meta files would be expected to be level 1 = or > greater.=20 I never found a stable notation that provides a reference to whichever of my /usr/obj/BUILDs/*/usr/main-src/*.*/ the build is for. (I've been showing just main-amd64-nodbg-clang amd64.amd64 examples but there are many more.) MAKEOBJDIR, OBJTOP, etc. all looked to vary. But here the only place relevant is that one absolute path, no alternatives should be used as these other things move around for where they reference. MAKEOBJDIRPREFIX is another one that looked to vary, despite the environment assignment that I use to get things started. Note, too the :=3D use. .MAKE.META.IGNORE_PATHS ends up with no references to MAKEOBJDIR or the like for my additions, just absolute paths. (I've also done experiments with :tA in use in the :=3D assignment.) -V.MAKE.META.IGNORE_PATHS showed the correct result with my content. I may have inferred too much from that for my :=3D use. (May be -V should not be based on .MAKE.LEVEL zero content as it can be misleading vs. what will actually be used?) So I was hoping for a "assigned once and inherited" status relative to submakes for .MAKE.META.IGNORE_PATHS . >> .for ignore_legacy_tool in awk cap_mkdb cat cp crunchgen crunchide dd = egrep env file2c gencat grep gzip jot lex lb ln m4 mkcsmapper mktemp mv = patch realpath rm sed sh touch truncate uudecode uuencode xargs >> .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} >> .endfor >> .for ignore_other_tool in ctfconvert objcopy nm >> .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} >> .endfor >> .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} >> .endif >>=20 >> The :=3D use is how I avoided needing to worry about late binding >> substitutions for my additions (independent of the internals of >> make's specific .MAKE.META.IGNORE_PATHS handling). >=20 > Depending on value of MAKEOBJDIR the above may not work at all. > The default is >=20 > share/mk/src.sys.obj.mk:_default_makeobjdir=3D = $${.CURDIR:S,^$${SRCTOP},$${OBJTOP},} >=20 > In which case the above would not be correct. And I've not found any notation that is always correct but adjusts to what /usr/obj/BUILDs/*/usr/main-src/*.*/ I happen to be building for. The example that I've been showing is main-amd64-nodbg-clang with amd64.amd64=20 but there are other *-*-*dbg-* and *.* that I build for. (I have found multiple notations that work for -V.MAKE.META.IGNORE_PATHS .) I'm wondering if I need to invent a new, personal name that will not clash with official names and just use reference to to my name, adjusting my build scripts to provide the definition. So: I'm still searching for approriate notation, at least for the tmp/legacy/usr/ related paths. (The tmp/usr/bin/ experiment is more questionable it is appropriate overall.) Until I know a valid notational technique, expect to see experiments involved in what I do. Going the other way: if I'm to test something for you, let me know the context you want used instead of whatever my experiment status happens to be. >> For reference: >>=20 >> # more = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh >> kldload -n filemon && \ >> cd /usr/main-src/ && \ >> mkdir -p /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/ && \ >> script = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/usr/home/root/src.configs/make.conf" = SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/usr/home/root/src.configs/src.conf.amd64-nodbg-clang.amd6= 4-host" \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/BUILDs/main-amd64-nodbg-clang" \ >> make $* =3D=3D=3D Mark Millard marklmi at yahoo.com