Test fails with this error:

  Expression: readchomperrors(`$exename --startup-file=no --inline`) == (false, "", "ERROR: option `--inline` is missing an argument")
   Evaluated: (true, "", "") == (false, "", "ERROR: option `--inline` is missing an argument")

I guess that means the "new" getopt code enabled here really wants --inline=yes instead of just --inline. Of course that's an unacceptable regression, and should be fixed. (On the upside, that means people using a Julia on MSVC always suffered from this discrepancy, and now that we know, it can be fixed).

Given that this getopt code is from musl, but is fairly old (~2014?) the first thing I'd try is to see if their newer version works better, and whether it could be used. However, it seems to have been changed substantially, so I am not sure how viable this is.

Or one could just improve the code that we have already, it shouldn't be too hard for just this one usecase.

However, before I investigate either option, it'd be good to know whether this PR has any chance of landing at all -- if this is not something the Julia core devs want out of some principle, there is no point in me trying to fix this (and possible other) issue(s).

I think a change like this needs at least a deprecation cycle, where any args that fail due to this PR , would succeed but with a deprecation warning. Something that would show up in e.g. CI logs and give people a chance to transition.

Those two issues look probably fixed by https://git.musl-libc.org/cgit/musl/commit/src/misc/getopt_long.c?h=v1.1.18&id=cfd7b4acd55420deedd41e0614c9b614c73c743e and https://git.musl-libc.org/cgit/musl/commit/src/misc/getopt_long.c?h=v1.1.18&id=91184c4f16b143107fa9935edebe5d2b20bd70d8.

It does seem potentially useful to vendor our own here for consistency, so we could get the latest version there, or bundle another common one such as https://github.com/apple-open-source-mirror/Libc/blob/master/stdlib/FreeBSD/getopt_long.c

Would you be willing to update to the new musl code, so we do get consistent behavior on all platforms?

It should just require downloading those patches, and using patch getopt.c < $file.patch to update it

I will take another look

So I've looked into this a bit again, and got it working with the most recent getopt_long in musl. However, the code needs at least some patching, plus some hackery to avoid clashes between its symbol and those define in the systems' version of getopt(_long). How to handle that?

• forget about upstream and just maintain our modified version (and then possibly refactor it; e.g. get rid of the tons of global variables)
  • this makes in particular sense if there are further changes we expect to need to make
• carry a patch version, but in addition also the patch and/or the original sources and/or a precise description where the base / vendor version came from

Any preferences?

If we're unhappy enough, we can also use the command line parser in LLVM instead from libSupport, but I think it just hasn't been a major issue enough to be worthwhile making significant changes.

Actually when I just tried to rebase and update the PR, I noticed that PR #42586 was merged which actually removes the use of src/getopt.c (but the code was left in).

So I've now made PR #42703 which actually removes src/getopt.c, as it is currently unused. That doesn't render this PR here useless, though; it is still about resolving inconsistencies in how Julia parses its command line options between platforms.

If this is still a goal, then I can also revive this PR. E.g. since dropping support for "abbreviated" options like --proj=foo (instead of --project=foo) would technically be breaking, we can investigate switching to another implementation, such as the FreeBSD one as suggested by @vtjnash

It seems possibly still useful to vendor our own copy for consistency.

From a reading of this PR, it seems like it may still be relevant, despite the linked PRs merged?