Re: [Bug-gnulib] Rewrite stdbool_.h during build?

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just to be clear in advance, the following is mostly not intended to
be obstinate argument but more an attempt to understand the GNULIB
design goals further...

Bruno Haible wrote:

>Derek Robert Price wrote:
>
>>Is there a good reason that the stdbool module uses sed to rewrite the
>>@HAVE__BOOL@ tag into a 0 or 1 when creating stdbool.h using a
>>$(HAVE__BOOL) variable subbed into the Makefile via m4/stdbool.m4
>>rather than just AC_DEFINEing HAVE__BOOL in the usual idiom?
>
>
>The reason is that I plan to install stdbool.h alongside with some
libraries
>whose declares functions have 'bool' as argument or return type. I
haven't
>done it so far (gettext-po.h has some functions returning 'int' where
they
>actually should return 'bool'), but someday I'll do it.


How does the generation of stdbool.h at configure time facilitate this?

>Also it obviates the need for
>     #include "config.h"
>in sources that only include standard header files: <stdio.h>,
<stdbool.h>, ...


But if you _already have to generate the header file with information
gleaned by configure_, why in the world would you bother to avoid such
a well-know, well-used, and tried-and-true method of getting the
information from configure into the C header file as #include
<config.h>???

>>M$VC++, as one might expect of any compiler, not just an M$ tool,
>>breaks when it sees:
>>
>>#if !@HAVE__BOOL@
>>. . .
>
>
>Why would you feed the unpreprocessed file into the C compiler?


Because I made the mistaken assumption that the header would operate
like the other GNULIB headers, for instance fnmatch_.h & alloca_.h,
which meant that I could make build targets in MSVC++ that
automatically built fnmatch.h, alloca.h, and now, in my uninformed
model, stdbool.h, by simply copying the appropriate source file.

Consistency in use and operation, I would argue is an important
ergonomic consideration for any tool, programming or otherwise.  It
can reduce the learning curve dramatically and reduce the number of
intelligent people like myself who have to pester the mailing list for
information after every two or three GNULIB modules they decide to
install.  This can be an important advantage in a tool when it isn't a
trade off against a loss of important functionality.

I think I have argued an aspect of programming ergonomics, perhaps I
referred to it as intuitive design, as an argument for reordering the
arguments to some of the getline & getndelim stuff.  The patch was
agreed to by both Paul Eggert & Jim Meyering, but you never applied
it.  I can resubmit it if you would like.

>>Windows doesn't have any standard file search/replace tool like sed,
>>so it would be much easier if I could just copy the file stdbool_.h
>>file to stdbool.h on that platform to avoid creating new tool
>>dependencies in the CVS build.
>
>
>gettext distributes all Windows specific infrastructure in a directory
>called windows/, all OS/2 specific infrastructure in a directory os2/,
>etc. Part of this infrastructure is an stdbool.h file. The makefile
>just has to add a -I..\windows to the command line, and everything is
>fine without any preprocessing or file copying. You can do the same.


This is what I have done for stdbool.h for now.  Thanks.

>>Would a patch to switch over to #ifdef HAVE__BOOL be accceptable?
>
>
>No, I'm not inclined to reduce the general reliability and ease-of-use
>of our <stdbool.h> substitute for the sake of minimizing the effort
>to port to a particular non-POSIX environment. - What would autoconf
>and automake look like if the requirement was that the generated
>configure files come in .bat syntax and that the Makefiles are also
>acceptable to 'nmake'?


I completely agree with you where automake & autoconf are concerned.
The trade off of features versus convenience is completely in favor of
avoiding support for both batch and nmake in the case of autoconf &
automake.

I also dislike Windows as much or more than the next guy, probably as
much as or more than many GNU programmers, but CVS still has a large
Windows user base and I can't bring myself to leave them unsupported.
I'd feel guilty not leaving the poor saps some alternative to VSS.
;)  Besides, the CVS project was supporting Windows long before I
joined it and we get lots of bug reports every time the Windows build
breaks.

It seems to me that in a tool such as GNULIB, it is much easier to
support a mostly-conforming to ANSI-C tool like MSVC++, even if it
isn't always as POSIX as I might like, than it is to write automake &
autoconf to support batch and nmake.  In fact, I thought part of what
GNULIB was trying to do was provide substitutes for POSIX functions on
platforms that lacked them.  Just as an example, almost all of the
GNULIB modules I have tried to install have worked practically
out-of-the box on Windows.  Granted, the autoconf code doesn't work,
but with one look at the modules, a hand-edit of our
windows-NT/config.h, and a one-pass preparation of the Windows build
files, the GNULIB modules can usually be installed pretty quickly.  We
do the same for a few other platforms that don't support autoconf &
automake well, most notably VMS.

>Bruno


Sorry if some of this is annoying.  I find Windows pretty annoying
too.  Like I said, I just can't quite bring myself to abandon all of
the other poor saps who still feel they have to use Windows but aren't
working at Microsoft.  In the mean time, I'll keep advocating the open
source alternatives as much as possible and try to make sure users who
build the source noticed that CVS's win32.c file was renamed to
woe32.c (short for Windows Operating Environment, per the GNU
convention ;) and the like...

Thanks for your time.  I'm looking forward to your response,

Derek

- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAi+VALD1OTBfyMaQRAitoAJ9sB8zE8wn3toI8T+qbOjrVgg0J1QCg1598
wnRzhdwjRzhMf2AC7AAVgBo=
=al3T
-----END PGP SIGNATURE-----