Re: next steps from recent macOS fallout

["Amitai Schleier" <schmonz%schmonz.com@localhost>]

Sorry for the non-plaintext mail; I had found myself with some spare 
minutes and a device I don't usually use to post to these lists, and 
hadn't considered the consequences. Here's the same text, now with my 
usual mailer. Hopefully this is easier to read and reply to.

-----

For those of you following along with the various recent Xcode and 
Command Line Tools issues -- and/or for those of you for whom that 
discussion was too disorganized -- I've written it all up in one place: 
https://schmonz.com/2024/04/02/pkgsrc-on-macos-still-works/

Now that the quarterly branch is cut, some followups looking for 
volunteers:

1. The demote-zealous-errors-back-to-warnings workarounds in 
mk/compiler/clang.mk are currently selected after four separate compiler 
invocations. It'd be great to refactor it to fewer, provided we can be 
confident there's no change in behavior. Some possible approaches are 
mentioned in the clang.mk comments.

2. It's not just upstream clang 16 and Apple clang 15 that bring these 
new strictures. gcc 14 will too. So whatever we figure out for (1), 
ideally it can be shared with gcc.mk without much duplication.

3. We're all fairly sure lots of things break when 
implicit-function-declaration, implicit-int, int-conversion, and 
incompatible-pointer-types are promoted to errors, but we haven't tried 
measuring. An exploratory bulk build (on any normally well-functioning 
platform) would give us a picture. Maybe it's not as bad as we think. 
Even if it is, the results will let us make incremental progress at our 
leisure, possibly by borrowing patches from package systems such as 
Gentoo that have been throwing their backs into this for a while.

4. There's a slight risk that some packages are newly broken on macOS, 
if they're using m4 or yacc without declaring them in USE_TOOLS. (One of 
the workarounds for those busted tools is to provide no-op versions when 
they're _not_ declared.) If you see such a breakage, just add the 
missing tool declaration.

5. We might want to generalize this approach to provide dummy versions 
of all undeclared tools on all platforms, to help find and fix missing 
tool declarations. (This behavior would probably need to be default-off, 
default-on for PKG_DEVELOPER, and able to be turned off individually.)

I think that's everything. I may volunteer for one or more of these, but 
would definitely welcome some help.

- Amitai