[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