bug-gnulib
[Top][All Lists]
Advanced

[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





reply via email to

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