bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-standard types in public header files (was: Re: ssize_t)


From: Stepan Kasal
Subject: Re: Non-standard types in public header files (was: Re: ssize_t)
Date: Fri, 12 Aug 2005 16:39:56 +0200
User-agent: Mutt/1.4.1i

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.

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.

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?

Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]