From nobody Thu Feb 23 08:07:54 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 4PMlyM2Pmcz3t9TL for ; Thu, 23 Feb 2023 08:08:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4PMlyM05T4z3hqd for ; Thu, 23 Feb 2023 08:08:10 +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=1677139689; bh=9jFrbPud81hCDzVJ77XufiJMwiUKk/O7NzXzDhRyn7s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PlKVpZXuTuVRisaG2GhqoJHUf8wPpi6SARgHZWfJR4XMaQSPCK0+iChxb4mRNNDT+vs0nCH3okmEyhT91IjrGanxuF2T32D2ZVI26wx9foN6j2aab0RGQN7Wxlx+BJ24eBznm8yukrEr5Up7X9JOD2Fj/41Br6GrkpHYAnoqinKlDiTkixwNxNee3AP29qitFy3Qft3OlX6cJ6cLYkhKC2WOoWBVk9W8NIAtx13LHokUyrMIRZiqEl20ojrJIpyKBn/NoUh24dnsMKLjTd5VTtTFgz7Dj2Ew/rYiiYVwhBdJjYp9fHkkqMPDr0mQ/8rxB1U8fForXci3/d8AHJom9A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677139689; bh=7pfvO5bhJrz7cd1CGwbrVj85bfXo7Zt8WSGyEjXZeFG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=fx5zAd14qCYflQWVLSXGKN400PSXqonxA0/74pw788zb2lNRhEKlsMrNonAu2Y1cLljTscNjFRPwXZzAQ/FYQyE3OFDvsCl9NAbt+CynCAfy4EX5HfDYxM+BvaI+qSNtEmi/Ijd+KMXw4OsrrvazqdZ5Ts31KC4y/wGhuMx+wQ1EW/oT3WkwvCfUU/IIiN6gv9DZJAaA3owY+IOH4ErMi9S+A3v+nYOZtpXj2cNC09DuJaMv08WEqTAHo7XQe4AKYdVAxktnICamZT+NvfotZC5Z0ho35BeN1lUSyluP5Hv9nKMgZAgmfc0i6MkNZWF+5Cec+D9ky63+JwbQiKBVSw== X-YMail-OSG: m63VOaoVM1mA7c3Jv3jgu6I0Pmi_X5OCoJ4oJsEZsxNzpd.gT1hr9SyfkYlrceu OAdPQJLdLA3QMH1KJ8xKle92yl2pG2nDu7qeDhVeSdwbYHnGa6P5H3iereZCj0EVnuo5vF0y.CC0 DL4Ji8telxa4Jw6zDZn5UW69oMfClflOoBqv_XcNVj6rHjMe6RpuTM15gfjMxz5PXaDCTxn6J7En 4bKbKur6KVS5Y1j6OfwHqT0FqCcoIBH_jf.Co.TSu_wFsYYfR._ei8qPs1ub8RVRASlHCpeOIuGD sxXUyug3FrPv8FwbjqyVIZgQacTBJLAEAmTWJesJvbc7k7rAscA1a7xnh6K.eIK6i34Z0sAd6s1k ateW4tZlCUaDzfmD8k0Q5626gJzHXYEWMHf003p3snPFLrc_f.WPHM4t1GjAHaQBKTY4NJGI4QRy HoMCv9Vxg6BRiNzHUuyboGuiRipvRIr3qFLtje4Ee7K_0My.eSr0tOwv2AGKqliAmpHnFN7wPRmn gZAJoCWLmTs86BaH4pubTU2lUGHN9D5w5_37GOpWhzOPrsm81RX5l44FdymsFdGZt6yy1CV9crhn NkYoqW0QcPTMa_MVXzHZMdwN0IcbiDf8q3vpUgf0jyF3w9p5NIksdOFdFxi.4QjmM4kOUXq173Xf nvXfGBrvpFwfFhs41VEnlQG.4KsAw84ykm0P1hgAvP_InVD7wJK59sU0nZCSeS.9AIieYIhKFX8K DI0Foy1iqtuu2VJZeItF8jwp0sV1wroFn2Ig26wfcI7wL0YXCDsr7.to4x6f1_A78CwiWhQ31UX0 QKVVfGs8uodCSldFiE0ctj25xVpQLbHKTn3x09stxEngs8l5do9eau0R5uWM1rvoAESoVEUr2RFw DwHo66hBXKPo5V1K44ywyCUUW2hOwZNkkd1HNlBJ.F7PwjPAzWtnkwOSnHBwb5EluaB6deBu0Fnl _qGFuPSwIbQOLARMmMCAnDeXrym9aSHwOCtmW_pA7l53wWInVXQ_du2zaclUVKn16IPgsZTzOin2 9pHZrKt_ev5BIxWq9WHe.fkYlNg18b5S.0BxPzXUtLWuEYcm6_0th12LQ78gDajr6ud_SyK7noF6 VosADKNRBTYj0t8OMizR_R4sHZUGiNFBUY.5WaZQfDyQXjvcMw8oBIN_yBkETn.2.dN2SQv04bhl LDI.OlwA_H.FYA8yzdojzQBjOGI4g8sCphCX0d0cRmhaIWRD9QZxXgIFWy6otIQpXnPoHGAxLkYH H6lqIJKtne6umfBU1sIZLXTR17yRFjpiNtOZVvN4xcPUfmPOADKA7KCPiw7Kc7dmNd7mx9SmdmeX fx80E_mmrYmqh595G6k0hBWWsiAKiQn3ArCrZwqGBrfYvooOhR4T5aOPnF9c4oQwUiIBh5vCxOKo DweZLT50dzoO5YVrXTaI0tPkH3CmaIfSNVGaU2PZjk_9RU5jDJhtOVPU9S9MOaqLRp_g0y2fMCh5 HsYfhYB161X_kTAFiFijTHG_cFcvLAS7v_faSgthY2qYc3dnq7VJOOjNUwl3Vuypl2Y0GCsfoLSa 5L9yGRP_7nz_vfnUFpRQrVUQEMscgOIfbznHZCVqtOs_RXJR6EDWApPZD11UIXYF6weIwfDWr1R. 0YBktMEUuFGJMuaDHkbKeUZAppaaHk8Nc.p5ZiPw.oZ9cItp_b3xZrX.OQkVVLsNMqv49mB62kWO JhynoMFCpEPPem17Qj8PRicdwpSsEqQIOOjmjdfjYWxrFOk8c5nFfLwEFKAYAfnp6rDoZpBGiShG xg1gm_LWKQePhB5pGUj7SD59zdufmFWLQy9.epqBQQ8d8EzkEEXtPqXH39k0RdiAZb3Tx3CvpXYi 1WALjXzXSZ1jp5I0XJLfRnyefANsQnWJgIoYAZYAoXzEBMx4RPpCEowONOwKJkk.XAVCa6nC4SoQ LOGXT5beA1Z0jfqqgF14RAhQ1sf84zyQK0MXvoNETDV.bizEcj2wr2K8Wn.JBAznHXjaPQYvUzN. 8B5URlAVuaFkZ8_N5mI.0gq2JLpZtvM0HB56Zf7gyakyty6OpFLc2ZnV1sfRowrpAuz1wqCM0Dy6 0iKztUJzRFJWdg..G1uD9Pea7T_M5StwyF6WXUrjVs.dPhjnn1a6iZLFFNl934u2su4o0_WoTWAz aS6hEiX7b2QQ6M8kr7t22R7jmAa7crJvO8OVTYSXfv.P928Jsg0FUCtQgBedB3PQJ4RY4wjnx_2h SGbDjVSg0drN4Q.doN7kr4RO3RiLdlyQ3Tvf1YKDPx1SE42WQJqQ_9aY3SlVHKD.nk.Pw6PROiNL Wn_c- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Thu, 23 Feb 2023 08:08:09 +0000 Received: by hermes--production-ne1-746bc6c6c4-b6fc9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 746fe916046eb0e14074ece8bbce3ff0; Thu, 23 Feb 2023 08:08:05 +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: <72419.1677133429@kaos.jnpr.net> Date: Thu, 23 Feb 2023 00:07:54 -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> <72419.1677133429@kaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PMlyM05T4z3hqd 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 22, 2023, at 22:23, Simon J. Gerraty wrote: > Mark Millard wrote: >>>=20 >>> Is there anything under ${OBJTOP}/tmp that you don't want to ignore? >>=20 >> More than just _bootstrap_tools_links entries end up in >> ${WORLDTMP}/legacy/bin/ (so in ${WORLDTMP}/legacy/sbin/ >> via the symbolic link pointing to ${WORLDTMP}/legacy/bin/ ). >> So: yes. >>=20 >> Also, OBJTOP is not constant over all the parts of >> buildworld buildkernel . Having the late-substitution >> form of notation ${OBJTOP} might not be appropriate >> for the content of .MAKE.META.IGNORE_PATHS . >=20 > Fwiw .MAKE.META.IGNORE_PATHS is evaluated when meta_init() is > called after all the makefiles have been read - and had a > chance to influence .MAKE.MODE, so I'm not sure how varaiablity of > OBJTOP would matter? To my knowledge, there is no place to find documentation about when/how-often the .MAKE.META.IGNORE_PATHS original text is reevaluated other than the above statement or source code inspection. (Others have a similar status.) -dV -V.MAKE.META.IGNORE_PATHS use does list ${__MAKE_SHELL} but lists /bin/sh without the -dV . (So -V use does not give a direct clue at what you report.) I got past the issue using :=3D before reading the above. (I'm also using MAKEOBJDIR instead of OBJTOP currently.) >>> .MAKE.META.IGNORE_PATHS+=3D ${OBJTOP}/tmp/ >>=20 >> (Ignoring the variability of OBJTOP issue . . .) >>=20 >> I do not expect that would work: ignoring things >> it likely should not. >=20 > 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 leads to: # = ~/sys-build-scripts.amd64-host/make-main-amd64-nodbg-clang.amd64-host.sh = -dV -V.MAKE.META.IGNORE_PATHS buildworld buildkernel Script started, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:29:01 ${__MAKE_SHELL} /bin /lib /rescue /sbin /usr/bin /usr/lib = /usr/sbin /usr/share /usr/include /usr/local/etc/libmap.d = /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/ Script done, output file is = /usr/obj/BUILDs/main-amd64-nodbg-clang/sys-typescripts/typescript-make-amd= 64-nodbg-clang-amd64-host-2023-02-22:23:29:01 Note: I'm currently avoiding -jN for 1> Also, I'd rather grow a smaller set of ignores >> gradually to make it easier to detect if an >> addition starts causing a problem and can be >> backed out. Starting with everything ignored >> would make things much harder to figure out >> when ignoring creates a problem. >=20 > Yes. >=20 >>=20 >>> You might need ${OBJTOP:tA}/tmp/ >>> or both. >=20 > I found it necessary in the unit tests to add :tA to both TMPDIR > and .OBJDIR to get sane result on one test platform. >=20 >>>> It is using paths that match the -dM output lines ( sbin >>>> use despite sbin -> ../bin being a symbolic link). >=20 > use :tA if you want to ensure consistent results. So, for each: .MAKE.META.IGNORE_PATHS+=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} I need to form an overall :tA on the path? Something like: .if ${.MAKE.LEVEL} =3D=3D 0 .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 IGNORELEGACY_${ignore_legacy_tool}=3D = ${MAKEOBJDIR}/tmp/legacy/usr/sbin/${ignore_legacy_tool} .MAKE.META.IGNORE_PATHS+=3D ${IGNORELEGACY_${ignore_legacy_tool}:tA} .endfor .for ignore_other_tool in ctfconvert objcopy nm IGNOREOTHER_${ignore_other_tool}=3D = ${MAKEOBJDIR}/tmp/usr/bin/${ignore_other_tool} .MAKE.META.IGNORE_PATHS+=3D ${IGNOREOTHER_${ignore_other_tool}:tA} .endfor .MAKE.META.IGNORE_PATHS:=3D ${.MAKE.META.IGNORE_PATHS} .endif Such seems to make no difference to the text reported via -dV -V.MAKE.META.IGNORE_PATHS in my context. >>> I really need to add some unit-tests for these... >=20 > Done - not yet imported to FreeBSD though >=20 >> You may want to wait while I see if I can come up with >> a better example context to show things. I only just >> noticed the late-substitution potential issue and >> started looking for a way to avoid it, for example. >> (Either a value that does not vary or a form of >> causing up-front substitutions in my make.conf .) >=20 > Ok =3D=3D=3D Mark Millard marklmi at yahoo.com