James Youngman wrote: > Perhaps something like this? > > posix - for implementing POSIX functionality on broken systems > glibc - for gnulib's implementation of functions available on GNU > systems but not posix (i.e. for things we should sometimes sync with > glibc)
This will increase the lookup time for someone who is not very familiar with standards. For example, would you look up 'strndup' in the posix or glibc directory (knowing that 'strncpy' is in POSIX)? Would you look up 'iswblank' in the posix or glibc directory (knowing that the Linux man page of 'iswblank' says that it's a GNU extension)? Then also the question comes up why not also a 'c99' directory. And when some glibc functions make their way into POSIX, we need to move the modules. > I think also some other arrangement might work: data structures, > string functions and math functions seem to be quite numerous. Such a categorization is probably good for categorizing the gnulib inventions, from 'acl' to 'xvasprintf'. But I'd say, it's good to make it clear where gnulib is implementing a standard and where it's defining an API of its own. For the standardized APIs, a categorization according to data / string / file functions doesn't have the three benefits that the headers / functions categorization has. Also, a certain number of modules (such as 'sysexits', 'putenv') don't really fall in one category, so it would be leftover at the top level. We also have the MODULES.html documentation. There is no need to use directory names to express something that the documentation already does. Bruno
