bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] sysexits.h


From: Simon Josefsson
Subject: Re: [Bug-gnulib] sysexits.h
Date: Wed, 11 Jun 2003 11:48:27 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

James Youngman <address@hidden> writes:

> On Tue, Jun 10, 2003 at 09:50:04PM +0200, Simon Josefsson wrote:
>
> [...]
>
>> #ifndef _SYSEXITS_H
>> #define _SYSEXITS_H
> [...]
>> #endif /* _SYSEXITS_H */
>
> This is something of a minor nit, but names starting with an
> underscore and then a capital letter are within the part of the
> namespace which ISO C reserves for use by "the implementation" (there
> are also other prefixes which have the same restriction).  Since we
> are providing a replacement header file, we can be sure that we are
> _not_ part of the "implementation" (since provision of sysexits.h by
> the implementation would make it unnecessary to use this file).
>
> I believe that this indicates that a more suitable approach would be 
>
>
> #ifndef INC_SYSEXITS_H
> #define INC_SYSEXITS_H 1
> [...]
> #endif
>
> .... however, I have never observed this to have been a problem in practice.

I borrowed the boiler plate from exit.h in the same directory, and it
appears that several files look the same (alloca.h, binary-io.h,
getopt.h, ...).  Should I worry about this?

This thread now contain many good suggestions for things to think
about when adding new modules.  Since I'm starting to have trouble
remembering them all by now, I think it would be useful to add a
simple README-dev or similar.  What do you think?  A starting point
could be:

How to add a new module:
* Write modules/<module> based on modules/TEMPLATE.
* If the module needs autoconf hooks, write m4/<module>.m4
* Add module to MODULES.html.sh.
* Add header and source files to lib/.

Test that a module builds with:
   $ ./gnulib-tool --create-testdir --dir=/tmp/testdir module1 ... moduleN
   $ cd /tmp/testdir
   $ ./configure && make

Other things:
* Check the license and copyright year of headers.
* Add source files to config/srclist* if they are identical to upstream.
* Include header files in source files to verify the prototype.
* Make sure replacement functions doesn't cause warnings on systems
  that have the function.
* Autoconf functions can use gl_* prefix, the AC_* prefix is for
  autoconf internal functions.
* Try to prevent that the files are built if they aren't needed on a
  platform.  Valid excuses to this rule include ELIDE constructs (see
  getopt module).
* Don't use AM_CONDITIONAL since it is fragile/heavyweight.





reply via email to

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