Re: Non-standard types in public header files

[Simon Josefsson]

Stepan Kasal <address@hidden> 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