Hi, I'm using replacement getopt.h, getopt_int.h, getopt.c and getopt1.c files to get GNU getopt_long support on systems where standard library doesn't do that. In Nettle, I do that the simple way, unconditionally building and using using the included files, no related configure checks or anything. I use the getopt_long function for a few peripheral command line tools, not included in any way in the installed libraries.
Now, I copied these files from glibc-2.19 a decade ago. And the old version is starting to cause problems on non-glibc systems, because proper prototypes are used only for glibc systems. (See, e.g., https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107059). So I'd like to fix this, and I have a few options. 1. Just patch my ancient version to always enable prototypes. 2. Copy files from latest glibc release, and adapt to work in my environment. The upstream changes between glibc-2.19 and glibc-2.41 are a diff of about 1200 lines to getopt.c (somewhat larger than the file itself) and some moving around of header files. I think the glibc files are still intended to be usable standalone, but current getopt.h header, which now includes <bits/getopt_core.h> etc, can't be used as is. And I imagine the standalone use case has seen less priority in recent years, after gnulib became the recommended and supported way of getting GNU getopt. 3. When I asked on the gnu-prog-disc list, it was recommended that I use gnulib, which is why I send this email. I tried running ./gnulib-tool --gnu-make --import --dir ~/hack/nettle getopt-gnu That command gives me * a lib/ directory with 7000 lines (to be compared to the 1800 lines of the actual getopt implementation, and the total of about 77000 lines of .c and .h files that go into the Nettle libraries). Largest single file here is unistd.in.h. * an m4/ directory with 6500 lines (compared to my current configure.ac + aclocal.m4, totalling about 1800 lines). Largest single file here is gnulib-common.m4. This is more overhead than I had hoped for, and certainly more than I'd want to take in for a release focused on bug fixes. I see a lot of value in having some kind of standalone GNU getopt, to make it easy to use getopt_long and GNU conventions for command line flags (both in GNU packages and elsewhere in free software). But I think this amount of overhead is excessive for use cases like mine, "I just want to use getopt_long in a few command line tools". Would you consider adding some minimal gnulib module that produces just the getopt source files needed for standalone usage, with system dependent things (e.g, use of stdio locking and gettext) simply disabled by default? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.
