Re: Non-standard types in public header files

[Stepan Kasal]

Hello,

On Sat, Aug 13, 2005 at 07:30:21PM -0500, Albert Chin wrote:
> Look at how glib solves a similar problem. Of course, they define
> their own types but they install a platform-specific .h file in
> $prefix/lib/include (glibconfig.h). This is similar to the
> gnutls-config.h suggested by Stepan Kasal.
> 
> AC_CONFIG_COMMANDS([gnutlsconfig.h],
> [
>   outfile=gnutlsconfig.h
>   cat >$outfile <<_EOF_
> #ifndef __GNUTLSCONFIG_H__
> #define __GNUTLSCONFIG_H__
> 
> _EOF_
> 
>   if test x$HAVE_SSIZE_T = xyes; then
>     echo '#define GTLS_SSIZE_T ssize_t' >>$outfile
>   else
>     echo '#define GTLS_SSIZE_T long' >>$outfile
>   fi
> 
>   echo '#endif /* __GNUTLSCONFIG_H__ */' >>$outfile
> ])

yes, this is similar, but not pure enough, I think.

I think that gnutlsconfig.h should contain only information bits about
the system, with comments similar to what you see in config.h.
So it would #define GNUTLS_HAVE_SSIZE_T or not.

Currently, glib's configure.in contains:

        outfile=glibconfig.h-tmp
        if test x$glib_limits_h = xyes; then
          echo '#include <limits.h>' >> $outfile
        fi
        if test x$glib_float_h = xyes; then
          echo '#include <float.h>' >> $outfile
        fi
        if test x$glib_values_h = xyes; then
          echo '#include <values.h>' >> $outfile
        fi
(glib_values_h is set to yes only if limits.h or float.h is missing).

Instead, it should define GLIB_HAVE_LIMITS_H, GLIB_HAVE_FLOAT_H and
GLIB_HAVE_VALUES_H to 1, if the headers are available.
Another file, say gnutls-features.h, would

#include <gnutlsconfig.h>

and then:

#if GLIB_HAVE_LIMITS_H
# include <limits.h>
#elif GLIB_HAVE_VALUES_H
# include <values.h>
#endif

#if GLIB_HAVE_FLOAT_H
# include <float.h>
#elif GLIB_HAVE_VALUES_H
# include <values.h>
#endif

Simon said that public header should work with any of the compilers on the
host.  While we cannot fully achieve this, this setup can help.
If the description in gnutlconfig.h happens to be inacurate, the user can
supply it's own copy, editing some of the bits.  (It might even work! ;-)

This rationale is similar to why we have config.h.in; in rare cases, users
can use it as a form to fill...

Another reason is that the constant gnutls-features.h header shows all the
possible alternatives, and gnutlsconfig.h selects which should be executed.

With glib, I cannot see the other alternatives, unless I look into
configure.in.  (Which is not installed, of course.)

A few days ago I consulted glibconfig.h for the definition of
G_GINT64_CONSTANT.  I saw only one definition, so I assumed it's the only
one.  Perhaps I have compromised the portability of the package I was
working on, because of that false assumption.

Hope this essay will help you to make the right decision.  ;-)

Happy hacking,
        Stepan Kasal