[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
group modules into subdirectories
From: |
Bruno Haible |
Subject: |
group modules into subdirectories |
Date: |
Thu, 29 Mar 2007 01:10:42 +0200 |
User-agent: |
KMail/1.5.4 |
gnulib now has more than 600 modules, some of which are already in
subdirectories. Still, there are more than 500 modules at the top level.
I propose two new subdirectories in the modules directory, with the aim of
clarity:
1) a subdirectory headers/
2) a subdirectory functions/
The headers/ directory shall contain modules that each provide one POSIX or
glibc standardized header file (without providing the functions).
The functions/ directory shall contain modules that each provide one POSIX or
glibc standardized library function.
Modules that don't fit into these categories just stay at the top level;
I don't want to enforce categorization schemes that possibly don't fit.
So far, in the headers/ category we would have:
arpa_inet
fcntl
inttypes
math
netinet_in
search
stdbool
stdint
stdio
stdlib
string
sys_select
sys_socket
sys_stat
sys_time
sysexits
time
unistd
wchar
wctype
In the lib/ directory, only comments and warning messages are to be updated.
In the m4/ directory, nothing changes.
The expected benefit is that
1) that people looking for a particular function and whether gnulib
support it can find it immediately, without grepping the repository
or the MODULES.html file,
2) by looking at the name of the module, you can tell faster what it
does. For example, the fcntl and time modules provide a header, not
a function - this is not clear for an outsider.
3) when a gnulib developer searches for the idioms used for headers or
for functions, the "pure" idioms are easier to find.
The immediate trigger for this request is that I want to have an 'iconv'
module that checks for the iconv library+header, and also a module that
provides a replacement <iconv.h> header. The module namespace is getting
narrow if we don't group them into subdirectories.
Objections?
Is it worth leaving "symbolic links of modules" in place of the old module
names, and have gnulib-tool warn about uses of the old module names,
to make transition to the new module names smoother?
Bruno
- group modules into subdirectories,
Bruno Haible <=
Re: group modules into subdirectories, Simon Josefsson, 2007/03/29