Hi, Niels Möller wrote: > 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.
unistd.in.h generates no code, does not make your binaries larger. Therefore why do you care about its size? The reason unistd.in.h is generated is that part of the getopt_long interface, namely the 'optind' variable etc., are also declared in unistd.h, therefore need to be overridden there when they are overridden in getopt.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. The .m4 files not only generate no code; they actually make your binaries smaller on GNU systems: They arrange to *not* compile getopt.c on systems that have it already in libc. Again, why do you are about the size of the *.m4 files? Isn't that the wrong metric to use? > 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". Do you also want it to elide the added code when the code is already in libc? Do you also care about having the portability problems fixed? https://www.gnu.org/software/gnulib/manual/html_node/getopt_005flong.html > 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? We can discuss small improvements. But adding a module that, on GNU systems, needlessly duplicates code that is already in libc is not among our plans. Bruno
