Stepan Kasal <[EMAIL PROTECTED]> writes: > Hello, > > this mail is a lengthy story "to the most abstract solution and back > to the basic one". Sorry, I couldn't have helped. > >> The problem, of course, is that the installed header file cannot >> assume a config.h and the HAVE_* stuff. > > Indeed, this is the root of the problem.
I'm not sure. Config.h stuff is tailored specifically to one set of compiler and compiler flags. A public header file should work regardless of whether you run the compiler in 32 or 64 bit mode, or regardless of which of the many C compilers that e.g. AIX ship with. > You try to find a solution which works without config.h. But this > means that the installed headers contain have the required bits of > information in a cryptic way. > > I'd pull the other end of the rope. If the information from config.h > is needed, we can just install config.h along with the public headers. > > Of course, we have to use a different name for it, like gnutls-config.h, > and we probably don't want to install the whole config.h, but just part > of it. Essentially, this is with foo-int.h created by Guido's macro is, but only for ?int*_t types. > There are several ways how to get the subset of config.h: > > 1) create a make rule which would generate the subset from config.h > > 2) Both headers would be generated by configure, the template for the > subset would be maintained manually. Look at > http://cvs.gnome.org/viewcvs/goffice/ > to see this in work. > > 3) Both the subset and the main config.h would be generated by > autoheader. First, autoheader would have to be enhanced, according > to this proposal > http://lists.gnu.org/archive/html/autoconf/2005-05/msg00054.html > Then, you'd give "gnutls-config.h" as the fourth parameter to the > AC_DEFINEs which should go there. > And then you'd probably need AH_BOTTOM([#include <gnutls-config.h>]) > to include the subset into the main config.h. > > I'd prefer the last solution, but it requires a non-existent feature > of autoconf > 2.59. :-) > > Then we get back to gnulib: how could gnulib-tool easily hook into > this? > > With solution 3): > The gnulib m4 files would contain calls like this: > > AC_DEFINE([PUBLIC_SYMBOL], 1, > [A description]m4_ifdef([gl_FEATURE_HEADER], [, gl_FEATURE_HEADER])) > > As soon as would the user define macro gl_FEATURE_HEADER, the "public" > symbols would go to a separate file. > > But does this work? How can gnulib maintainers know which defines > are needed by your public headers? The maintainer of the project has > to define the subset for "gnutls-config.h". > > So actually, it might be better to use the solution 2), with manually > defined subset of config.h. > > But since the AC_DEFINE calls are not under your direct control, they > are brought by some third party macros, there is a danger that some > AC_DEFINE will disappear from configure and you won't notice it. > > So, after all, it seems that in your case the most robust solution > might be 1). The script would not only select the #undef lines and > accompanying comments, it would also check that all expected symbols > were actually seen. So if an expected symbol disappered from > config.h.in, the script would cry. > > End of my tale. Is it useful for you? I appreciate your ideas. I'm still not certain exactly how I want this to work. Perhaps I'm intimidated by the complexity of Guido's macro. I need to think more about this. Thanks, Simon _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib