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>