bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: group modules into subdirectories


From: Bruno Haible
Subject: Re: group modules into subdirectories
Date: Thu, 29 Mar 2007 13:06:43 +0200
User-agent: KMail/1.5.4

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]