[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Non-standard types in public header files
From: |
Simon Josefsson |
Subject: |
Re: Non-standard types in public header files |
Date: |
Fri, 12 Aug 2005 18:35:17 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) |
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
- ssize_t, Simon Josefsson, 2005/08/12
- Re: ssize_t, Bruno Haible, 2005/08/12
- Re: ssize_t, Simon Josefsson, 2005/08/12
- Re: [bug-gnulib] Non-standard types in public header files (was: Re: ssize_t), Bruno Haible, 2005/08/12
- Re: Non-standard types in public header files, Simon Josefsson, 2005/08/12
- Re: Non-standard types in public header files, Albert Chin, 2005/08/13
- Re: Non-standard types in public header files, Simon Josefsson, 2005/08/15
- Re: Non-standard types in public header files, Stepan Kasal, 2005/08/25
Re: ssize_t, Karl Berry, 2005/08/12