[patch] Don't add PTH include path to gpgme's CFLAGS globally

[Marcus Brinkmann]

At Tue, 13 Feb 2007 07:33:07 +0100,
Michael Nottebrock <lofi at freebsd.org> wrote:
> 
> Marcus Brinkmann schrieb:
> > At Mon, 12 Feb 2007 18:04:06 +0100,
> > Bernhard Reiter wrote:
> >   
> >> [1  <multipart/signed (7bit)>]
> >> [1.1  <text/plain; iso-8859-1 (quoted-printable)>]
> >> Werner,
> >>
> >> On Monday 12 February 2007 15:21, Werner Koch wrote:
> >>     
> >>> There is also the strange change in Pth to make soft mapping of system
> >>> calls the default.  This requires many applications to explicitly
> >>> disable the soft mapping.  In fact, I consider this an API change.
> >>> The default Pth m4 tests are not able to grok such a change.  That is
> >>> why some libs have the "foo-config --api-version" feature to allow
> >>> checking for an such API changes.
> >>>       
> >> thanks for the explanations. Can you add something
> >> what this means for this patch? What is the conclusion?
> >>     
> >
> > Won't fix, bug is in the distribution, at least for now, until either
> > someone convinces us that making Pth's pthread.h available was a good
> > decision to make, or the world charges ahead and drags us with it
> > kicking and screaming.
> >   
> See my other reply, Pth will install its compatibility header no matter
> what. Surely it's easier to add my trivial patch to gpgme than adding a
> not entirely trivial additional configure check to Pth? While at it, you
> could also update the ancient assuan subdir from early gnupg-devel days
> that is still included with gpgme and which requires several patches to
> build on FreeBSD.

Let's go through this one by one:

1) If Pth installs pthread.h even if --disable-pthread is given on the
configure command line, I think that's a bug.

2) If you build Pth with --enable-pthread on a system with native
pthread support, I think that's a bug.

3) In general: If there is a pthread.h in the include path that
doesn't work as it should, I think that's a bug.

With which of these three statements (if any) do you disagree?

The assuan directory in GPGME is current as of december 2006 (released
in GPGME 1.1.3).  Since then, only two small changes have been done in
libassuan, which should not affect current usage.

Thanks,
Marcus