re: dont! Re: stdbool macro, take 2

[Guido Draheim]

Es schrieb Bonzini:
> 
> > So AC_HEADER_STDBOOL should remove any preexisting stdbool.h before
> > doing any tests that depend on stdbool.h.
> 
> Fixed.
> 
> > I don't see why this would be needed.  `make distclean' can just
> > remove stdbool.h unconditionally.
> 
> Right.
> 

being a person who has been doing some tricky stuff with a generated
file called stdint.h, I would like to oject on generating a stdbool.h
file for a specific reason - installable headerfiles of a project. If
you want to make sure that some of your exported interface function
can use the bool datatype then you must make sure that this type will
actually exist - in the context of that other app using a library,
and there is (of course) one best thing - include some system headers
that will define it. 

so, how to go from here - one way is to install a missing stdbool.h
file along with your public headers but this will break if there is
another package (thinko rpm et deb) that will want to install the
samenamed file, possibly with a different version of code contained
in it. And when you distribute it into a subdir that will require
another package to have an additional includedir (thinko of a
sdl-config --cflags returning -I/usr/include/SDL) you will have a
hard time if another library will do the same thing - which header
will be taken does depend on various effect of the order these
things are given.

A generated stdbool.h file will therefore be only valid for some
apps that do not install public headers - basically no libraries
I guess. This is of limited use and should not go into autoconf.
If you need a bool datatype (or other defs that shall go into
this lib) one should make sure to have it dumped into another
file that will not possibly offend with a "standard system header"
that might be possibly coming in later from a dedicated devel
project, e.g. http://ac-archive.sf.net/gstdint for stdint.h and
where I took the path to not overload the reserved name that was
for usage by the C compiler make (that could be up with an update).

sorry for cutting in so late, I was not attending closely for 
having somewhat too much work lately - basically I strongly recommend
to not go with a make-stdbool.h and put it into autoconf for an 
unexperienced user to happily use it along and coming in later blaming 
for the problems it will make later on. To give it another take - what 
header files are generated with any autoconf macro? The other thing is
correct - you can generated a proper C file to be compiled in just
this project but do not do that with a header file - it will be
misleading.

There are of course other paths that are more appropriate - one way
that I tried upon: make the default name different (possibly without 
a default) and have it #define a check that it will check for itself 
to see if another header file has already typedef'd it (to avoid typedef 
collisions, possibly from a different C compiler or another lib) and 
have a say on need_bool and friends with a whole lot of other problems.

And all this just circumvents the traditional path which is there for
a reason in so many library headers - define a prefix and use the
basic types and modifiers with that prefix, coming to gint and gboolean
and whatever. After all, I wrote that prefix-the-config.h-defines macro
for a reason to have it installable if I just have a normal config.h
"#define bool" from a standard bool-typedef check like we do for const.
Sure, all these do not apply if the header file is only generated for
this project and never installed - but in that case, it should not
be called stdint.h either, call it stdint.inc and make an ifdef
HAVE_STDINT_H like everyone else, with an #else part including the
local inc-file. It's just the C source and no header file after all.

cheers, guido 
p.s. references are
    http://ac-archive.sf.net/gstdint
    http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html