bug-gnulib
[Top][All Lists]
Advanced

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

Re: errno --> errno name ?


From: Bruno Haible
Subject: Re: errno --> errno name ?
Date: Sun, 14 Aug 2011 19:25:23 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Bruce Korb wrote:
> > Does the .h file need to be generated? It is much more convenient to
> > rely on a .h file that is platform independent.
> 
> The formatting string depends upon the maximum errno name length.
> If one can presume 16, then there's no need....  It seems to be 15
> on Linux:

Then, I would
  1. define the macro with value 15 in the .h file,
  2. document that this value may be increased in future versions,
  3. add a warning to the mk-err-names.sh script when an error name
     is encountered on some platform that is longer than 15 columns.

By the way, instead of defining a macro ERRNO_DISPLAY_FMT (that ends with
a newline - why?), it is more general to define a macro
  #define MAX_ERROR_NAME_LENGTH 15
Users who want to user columns can then do things like
  printf ("%.*s", MAX_ERROR_NAME_LENGTH + 1, ...)

> > then retry "make", nothing will happen, because
> >    1. err-names.c does not depend on mk-err-names.sh,
> 
> It depends upon the .h and the .h depends on the script.

Ah, ok, sorry. I was looking at one rule only.

> Please feel free to tweak it.  I think that might be easier than
> seeing if I get exactly what you mean, retrying and cycling again.

But through this process of proposing, retrying, and listening to comments
you (and others who read the mailing list) learn about the technique how
to design a usable, generic, and at the same time practical API; about the
considerations specific to gnulib; about the things to remember regarding
VPATH; and so on.

> > Also, the rule does not work in VPATH builds where $(srcdir) != ".".
> 
> Okay, need to pass through CC and srcdir both.  See above.  Note also
> that by changing the script so that the files get created in the
> source directory, you also make it possible to fail because the source
> directory isn't necessarily writable. I think the source ought
> to be generated in the "build" directory.

Yes, you are right, the $(srcdir) may be read-only. Actually Automake's
"make distcheck" rule verifies that you aren't writing into $(srcdir)
if $(srcdir) != ".". -- I didn't suggest to generate the files in
$(srcdir). All I said was that the Makefile rules would fail in the VPATH
case.

> I don't exactly see how the VPATH build fails.

It will not find the mk-err-names.sh script in the first place. The Makefile
rules are executed in the build directory.

Please, that's part of submitting a gnulib module: adding it to your
gnulib working directory, doing "./gnulib-tool --create-testdir ..." of it,
and optionally testing this testdir with "mkdir b; cd b; ../configure; make".

Bruno
-- 
In memoriam Maximilian Kolbe <http://en.wikipedia.org/wiki/Maximilian_Kolbe>



reply via email to

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