Hi Bruno, Bruno Haible <br...@clisp.org> writes:
> The patch is technically correct, AFAICS. Except that I would prefer the > file to be named fts.in.h instead of fts_.in.h. > > We have a common naming idiom that the include file names should be the > same as the customary ones in Unix. So that applications don't need to > use different .h file names when they start using a Gnulib module. > For example, there is a system <getopt.h> and a Gnulib <getopt.h>. > Here too, we should have a system <fts.h> and a Gnulib <fts.h>. > Maybe we'll change that: fts_.h → fts.h. It's not urgent, but better > be prepared to remove this irregularity. > > With the file being named fts.in.h, it feels more regular / consistent > with the other Gnulib modules. Adding Jim to the CC since he is listed as the as Maintainer in the module description. I don't really like the fts_.h name either, but I think it was named that way because the 'fts' module unconditionally replaces the system definitions even on glibc. But having fts_.in.h generate fts.h feels strange to me. Jim, what do you think about renaming the file to fts.in.h which generates fts.h? Since the Gnulib functions are always used, we can just skip the #include_next <fts.h>. We can provide a fts_.h that just includes fts.h similar to getprogname.h that just includes stdlib.h. Collin
