On Sun, Jul 21, 2024, at 12:40 AM, Eric Gallager wrote: > Hi, I'm writing because I will occasionally see messages like the > following from CI systems (specifically GitHub Actions' macOS runners) > when they attempt to run autoconf: > > /Applications/Xcode_15.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gm4: > unrecognized option `--gnu' > Try > `/Applications/Xcode_15.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gm4 > --help' for more information. > autom4te: error: gm4 failed with exit status: 1 > > My first attempt at fixing this was hacking in support for the `--gnu` > flag for Apple's copy of gm4, but since the apple-oss-distributions > organization has pull requests turned off, there isn't much I can > really do there to get Apple to upstream it: > https://github.com/apple-oss-distributions/gm4/compare/main...cooljeanius:apple-gm4:gnu_flag
Yeah, don't bother. Their copy of GNU M4 is too old for us _anyway_. They ought to either get over their GPLv3 phobia or stop shipping GNU utilities at all. > I think what is happening here is that > [g]m4's support for the `--gnu` flag gets detected at autoconf's > configure time, but then when the user overrides the M4 variable to > point to a different [g]m4, the M4_GNU variable stays set to whatever > it was first detected as, which might not match up with what the new > [g]m4 supports. I'm wondering if there's some way that autoconf could > shift around the timing of these checks so that it doesn't try passing > `--gnu` to an installation of [g]m4 that doesn't support it? It probably _would_ make more sense to do that check at runtime, in autom4te. I'll think about how to make that happen. zw
