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
