#19 Mismatched getopt.h used

[Daniel Macks]

On OS X, we appear to have sufficient getopt support available in the standard system libraries:

checking for getopt_long... yes
checking whether getopt_long reorders its arguments... yes

and so the source-distro's own src/getopt.c and src/getopt1.c are not built (EXTRA_OBJS is blank). But src/getopt.h is still present and so compiling other .c within src/ #include that local copy rather than the system's own. For example:

Making all in src
clang -DHAVE_CONFIG_H -I. -I.. -I/sw/include -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c

gives a .deps/main.po that notes:

main.o: main.c [...] getopt.h

whereas if I rm src/getopt.h that instead reports:

main.o: main.c [...] /usr/include/getopt.h

The solution is probably to push the getopt files into a getopt/ subdir and then only pass its -I if needed (EXTRA_HEADERS=-Igetopt analogous to EXTRA_OBJS, and likewise adjust the EXTRA_OBJS paths for this subdir).

[Peter Selinger]

This is an interesting point. Normally, #include <getopt.h> should include the system-wide file, and #include "getopt.h" should first try to include the local one. That is the difference between the <...> syntax and the "..." syntax for #include.

However, this behavior is made moot by the fact that our command line includes "-I.", as the local directory in effect becomes a system-wide one.

In principle, it doesn't matter if our local getopt is used, even if there is a system-wide one available. But in the current setup, the local header is used together with the system-wide object file, and while this is probably okay (the prototype for getopt is pretty standardized), it is clearly not ideal.

I'll investigate the best way to solve this. Thanks, -- Peter

[Peter Selinger]

Yes, moving getopt.h into a subdirectory seems to be a good solution. It will be fixed in the next release.