[Csync2] csync2 without gnutls-openssl?

Giampaolo Tomassoni Giampaolo at Tomassoni.biz
Wed Jul 28 16:47:51 CEST 2010


> > Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
> > pkg-config/gnutls-config isn't that much relevant with respect to the
> > autogen.sh failure.
> 
> Yes, it is undefined, because it should be (or used to be) in the dev
> package of libgnutls, but no longer is, because they apparently decided
> they had a better approach.

It seems to me they simply discontinued support of that m4 macro.


> > In the patch shipped with my previous message, the m4/libgnutls.m4
> file was
> > exactly meant to define the missing macro.
> 
> Yes.
> And your patch even fixes a build breakage.
> So it is good.
> Only it seems to be not what libgnutls upstream seems to want.
> So I figured, if you already hacking there anyways, maybe just do it
> the
> way gnutls upstream feels would be the right way.

I probably miss the why you think they like a somehow different way of
detecting their lib.

Do you have any reference, url or whatsoever about it?


> > Do you perhaps mean you prefer to have the AM_PATH_LIBGNUTLS
> AC_DEFUN[]
> > stuff directly into configure.ac, instead of having it in the
> > m4/libgnutls.m4 file?
> 
> I don't care either way. But if gnutls still things this macro should
> be
> how autofoo should be done, then they should package it themselves,
> just as it used to be. Or we should do whatever they feel is the right
> way to gnutls autofoo integration now.
> 
> It cannot possibly be their intention that any libgnutls user should
> have its own private copy of libgnutls.m4.
> 
> Am I misunderstanding something?

Well, I really don't know. I however see that most libraries don't ship
their own way of detecting themselves: most of the times m4 detection macros
have to be "shamelessly stolen" and/or handcrafted from some other package.

I guess the problem is that detection macros need often to be tuned for the
specific needs of the package using them, not only for the one offering the
feature.


> Is this just a packaging error of libgnutls?

I think they switched to pkg-config and they supposed that the "stock"
PKG_CHECK_MODULES was then enough to detect their package.

So, you may use the PKG_CHECK_MODULES macro offered by the pkg-config
package. Which means you have to put a copy of the pkg.m4 file into the m4/
dir of the csync2 package. Unfortunately, there possibly is people running
systems with a pre-2.8.x version of libgnutls, or even with no pkg-config
support. If you go straight with a pkg-config -only solution you're going to
cut 'em out.

Isn't it easier to ship the m4/libgnutls.m4 script, which covers both the
pkg-config and gnutls-config cases, instead of the m4/pkg.m4 one, which only
covers the first one?

Giampaolo


> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.



More information about the Csync2 mailing list