Why does the GNU coding standard prefer getopt_long over argp?

Question

I do not understand why the GNU Coding Standard has the following line in Section 4.2 - Writing Robust Programs

Use getopt_long to decode arguments, unless the argument syntax makes this unreasonable.

My understanding is that getopt is part of the POSIX standard, while getopt_long is specifically GNU. At that point, why not make argp the arg parser of choice for GNU projects? Argp is part of GNU libc and according to GNU's libc reference manual offers many advantages over getopt_long, as stated in Section 25.3

Argp provides features unavailable in the more commonly used getopt interface. These features include automatically producing output in response to the ‘--help’ and ‘--version’ options, as described in the GNU coding standards. Using argp makes it less likely that programmers will neglect to implement these additional options or keep them up to date.

Argp also provides the ability to merge several independently defined option parsers into one, mediating conflicts between them and making the result appear seamless. A library can export an argp option parser that user programs might employ in conjunction with their own option parsers, resulting in less work for the user programs. Some programs may use only argument parsers exported by libraries, thereby achieving consistent and efficient option-parsing for abstractions implemented by the libraries.

I would expect most arguments to center on portability. I think this is fine except for two things:

1. I haven't found a concrete case of increased portability of getopt_long (which is a GNU function, not the POSIX getopt) over argp
2. I haven't been able to find any reference of decreased argp portability over getopt_long in any GNU reference literature.

So to restate the general question one more time:

Why does the GNU coding standard prefer getopt_long over argp?

Answer 1

I must admit I had never even heard of argp before. Looking the the documentation, it seems way too complex for mundane use. getopt_long is bad enough already and at least it is supported by some non-GNU platforms.

For simple programs, getopt is just fine, getopt_long allows for long option names, so use it if you want long option names.

Trying to come up with a universal solution to a non problem is a good example of over engineering: even the promoters of the solution do not seem to be willing to make the effort to use it for existing packages.