[SCM] s3-build: expliticly require gssapi for HAVE_KRB5 and remove HAVE_GSSAPI

[Andrew Bartlett]

On Mon, 2012-02-13 at 17:15 -0500, simo wrote:
> On Tue, 2012-02-14 at 07:25 +1100, Andrew Bartlett wrote: 
> > On Mon, 2012-02-13 at 08:52 -0500, simo wrote:
> > > On Mon, 2012-02-13 at 06:14 +0100, Andrew Bartlett wrote:
> > > > s3-build: expliticly require gssapi for HAVE_KRB5 and remove
> > > > HAVE_GSSAPI
> > > 
> > > Sorry, but I do not get why you are using the wrong definition here.
> > > You do depend on GSSAPI not on krb5 raw libraries, so I would expect you
> > > drop the HAVE_KRB5 and instead require only HAVE_GSSAPI.
> > > 
> > > What's up with doing the reverse ?
> > 
> > As you have noticed, I was trying to follow up on our discussion about
> > the number of different variables used for this.
> > 
> > For this patch, it was simply the smaller change.  As you know, many any
> > of the our blocks of GSSAPI-dependent code are already protected with
> > HAVE_KRB5, because it is the only GSSAPI mech we really support, and for
> > some time now we have only supported krb5 with GSSAPI.
> > 
> > I'm sorry for not checking with you on the details of which name you
> > preferred, and I'm happy to sweep over the code base and change it all
> > to HAVE_GSSAPI if you like. 
> 
> I was just wondering why you went one way rather than the other.
> HAVE_GSSAPI seemed the technically correct one, and we may even have to
> go the extra mile, and define HAVE_GSAPI_KRB5 given we do depend on
> stuff in the gssapi_krb5.h extensions.

Part of what I was aiming for with the agreement to only support a
modern krb5 (I would like to change modern to mean MIT krb5 1.9 btw, due
to issues I've found with 1.8), my hope is to either have all, or
nothing. 

The rationale is to avoid #ifdef spaghetti, except where required to
deal with Heimdal/MIT differences. 

I would even like to avoid having to check for each function in
configure, by instead doing a pkg-config test on the version.  That way
we can start using new, mutually supported functions more easily.
(Users without a pkg-config file would still be able to manually turn on
our krb5 support, but if we fail to compile, it should be clear why). 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org