[Top][All Lists]

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

[Help-gnutls] Re: 1.2.9 release candidate

From: Simon Josefsson
Subject: [Help-gnutls] Re: 1.2.9 release candidate
Date: Tue, 01 Nov 2005 11:26:08 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Daniel Stenberg <address@hidden> writes:

> On Tue, 1 Nov 2005, Simon Josefsson wrote:
>>> Of course I can make a configure-check for them, but it would be
>>> nice with some simple preprocessor magic...
>> I think a configure check is the simplest solution available.  If
>> you don't want to pollute your source code with #ifdef's, you could
>> have configure define those two symbols to 0 if they aren't defined
>> by gnutls.h.
> Of course. But my argument was not so much of concern of how the
> #ifdefs will look in my code (libcurl being massively portable we have
> #ifdefs all over already), it is how my code figures out what the
> installed GnuTLS supports or not. (Or in this case, what the headers
> contain or not.)


> In OpenSSL land, I've almost always been able to avoid checking for
> version- 
> specific features in configure by using preprocessor magic such as
> checking for specific version numbers etc. Like this:
> #if OPENSSL_VERSION_NUMBER >= 0x0090581fL
> #else
> #endif

My experience has been that it is more reliable to test for features
rather than version numbers, even if it takes a few more line of codes
to do so.

>> I usually want to make the core code look good for the
>> latest-and-greatest features, and work around missing functionality
>> in earlier releases through some replacement stuff in configure.
> Well, you could easily just add a simple define in the header file
> next to the enums that we could #ifdef with to figure this out.

I have added:

    /* Increment this define if you add new enum's.  The purpose of
       this CPP symbol is to let application figure out which flags
       are supported through CPP checks in the code, and to avoid
       lengthy autoconf snippets in every application. */

so that your code could do


Does this solve your concern?  Did you have a better solution in mind?

> By ducking for this, you force every single GnuTLS-user out there to
> add feature-checks to our configure scripts. It might not bother you
> as author of the lib, but it bothers me and I see this in the big
> perspective and how this will affect us in the long run and how this
> will make our configure scripts having to check for more and more
> features should more of these things occur later on. (And I actually
> consider that more likely than that _no_ more such things will occur.)

If you don't want to add specific feature checks, you could always
require the earliest version of the GnuTLS library that you know
support everything you need, e.g.:

        AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no)

or something.


reply via email to

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