Date: Fri, 10 Feb 2023 08:29:33 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: dev-commits-src-all@freebsd.org Subject: Re: git: 0dfaefa97547 - main - depend-cleanup.sh: Simplify the logic, and clean bootstrap tools. Message-ID: <20230210082933.Horde.VHCBwWtyyCtEIbI1ni40V-Z@webmail.leidinger.net> In-Reply-To: <86ttzvw4qe.fsf@ltc.des.no> References: <20230209083133.Horde.q3w2RmVjVzPwrvCq2u6yNUU@webmail.leidinger.net> <86ttzvw4qe.fsf@ltc.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed.
--=_oF2r8I1B6sS3ZGcCXe-z8Ti
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Quoting Dag-Erling Sm=C3=B8rgrav <des@freebsd.org> (from Thu, 09 Feb 2023=
=20=20
10:46:49=20+0100):
> Alexander Leidinger <Alexander@leidinger.net> writes:
>> You change from "no fork+exec if the file doesn't exist" (due to "if"
>> and "[" being shell-builtins) to "always fork+exec". On fast machines
>> surely not an issue, on slow ones, it may make a difference (I have an
>> old amd64 machine at an ISP which takes days to do a buildworld with
>> -j2 due to not much memory, only 2 cores, old HDs, and other stuff
>> going on in parallel).
>
> Have you measured this? Because the whole point of clean_dep() is that
No, I haven't measured, for this reason I used "may".
> the file it looks for nearly always exists. It's the grep we're not
> sure of. So checking if the file exists is nearly always a waste.
Thanks for clarifying that.
>> While the .depend.* namespace is surely controlled by us, would it
>> make sense to change the glob to ".{o,pico}" instead of ".*o" instead
>> to prevent unexpected surprises in the future?
>
> Our sh does not support the {} syntax. Besides, what would it change?
> What else would match .*o but not .{o,pico}?
My point here is, that making this more specific (we can also list the=20=
=20
files=20explicitely), we _maybe_ can prevent foot-shooting in the=20=20
_future_,=20in case there is something else added. I've seen enough=20=20
cases=20where wildcarded removals caused harm after a little change in=20=
=20
some=20other place. I have no doubts that you checked that this=20=20
_currently_=20is working fine. Based upon my experience in=20=20
troubleshooting=20issues with "lost files" after an innocent change=20=20
somewhere=20else, I prefer to at least ask about it.
Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
--=_oF2r8I1B6sS3ZGcCXe-z8Ti
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmPl8lwACgkQEg2wmwP4
2IaVeQ/8DNQrqxCJBx+VwNP2EOXxRy/6lPEJ5Nj6uv1JgSyDm01RiVQwJyadBIG7
VrAKiDcE/R7STDJLHjFQAwKEedxHN6JRdPr9opLN+jb63FTg7HGjby8cK38CuHn/
eLCt3kD6uOUBJFEGK9M1QL6W1zERdCn6NBvCOgfwvQNFjsWdlAbk57EDcahSmfRz
yF9jHjTuhGVO2Xv3cyqoq2e1U1QbwH8eBVZ64NUN03WOVD1IymcQFYaqTI69FhHb
06Mfk6IZUKMygj8BqckhqjTHMO4c28w1he7R3UIAcc0WznAgH4Hfmomc9Yb29sR/
AnJLMzI4epLJZSdwZvBOPPzFvaOAbHgoWfWQrKvU/aFVCqlPFVn5o5XK0qQzECPU
Zcq3WYYf6YSgoAThCHeKk+QiZNDU2O3YEFpioebjUi20yy9PUKAtpzsZbc26uRTp
7ozUOKkaTAN+crPaVVONT8LtOxDRAyyd6myhOrvFef4vpVUS76hLq59X3a5UW8X/
Yzpu0MQ2tZPmyAizkaNNgAzk2W2rWvejHVxW+N5ig2O6xTuvLgoPVq6JfuxTWQkW
+GwOwOrM1i+GYSlivjFw57xSCDP3L/R+EJitRRUP1TtD+93wmoqjrAerj+FUIfyq
cNDIZGAow9tS5pucXDzaDijlSk4/TY64LvGWFLcKUxvhNmWvbtI=
=Fo8s
-----END PGP SIGNATURE-----
--=_oF2r8I1B6sS3ZGcCXe-z8Ti--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230210082933.Horde.VHCBwWtyyCtEIbI1ni40V-Z>