Re: pkg/55593: Proposed modification to buildlink3.mk of libxml2

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2020-08-28 at 22:50 BST, Joerg Sonnenberger wrote:

> On Fri, Aug 28, 2020 at 04:15:02PM +0000, Thomas Klausner wrote:
> > The following reply was made to PR pkg/55593; it has been noted by GNATS.
> > 
> > From: Thomas Klausner <wiz%NetBSD.org@localhost>
> > To: NetBSD bugtracking <gnats-bugs%NetBSD.org@localhost>
> > Cc: 
> > Subject: Re: pkg/55593: Proposed modification to buildlink3.mk of libxml2
> > Date: Fri, 28 Aug 2020 18:12:37 +0200
> > 
> >  On Fri, Aug 28, 2020 at 04:05:09PM +0100, Jonathan Perkin wrote:
> >  > * On 2020-08-21 at 18:59 BST, Joerg Sonnenberger wrote:
> >  > 
> >  > > On Thu, Aug 20, 2020 at 03:40:00AM +0000, you.kawasaki%gmail.com@localhost wrote:
> >  > > > I noticed that the CFLAG does not include "include/libxml2".
> >  > > > When I added following line in buildlink3.mk of libxml2 to include "include/libxml2" in the CFLAG, building finished without an error for handbrake.
> >  > > 
> >  > > So the short version is that this $#%^$%^$%^ hardcodes include paths for
> >  > > various systems and for Linux it falls through to explicitly using
> >  > > /usr/include. It should be using pkg-config like everyone... libxml2's
> >  > > b3.mk should most definitely not be changed for compensating for such a
> >  > > mess.
> >  > 
> >  > FWIW I just ran into this on a system building www/nginx also.
> >  > 
> >  > I don't see any _harm_ in adding the correct INCDIRS, it's what we do
> >  > for a lot of other packages, so I'm going to add it unless there are
> >  > serious objections.
> >  
> >  If you do it in the package that fails that's definitely fine.
> 
> I don't mind doing it in the leaves, but I do object to adding it to
> libxml2's b3.mk. Essentially, this is a hackaround for a steaming
> U+1F4A9 and the package here is definitely broken.

So why do we bother having BUILDLINK_INCDIRS in the first place?  What
problems are we solving by having to patch every leaf instead of just
fixing this in the infrastructure like we do for everything else?
What possible side-effects are there of adding include/libxml2 for
_only the configured libxml2_ to the search path?  It's not like we're
going to accidentally find some incompatible libz in there or
something...

Fine, I'll go around adding patches for everything that breaks due to
this, but it feels very against the pkgsrc philosophy, will mean
constant future maintenance burden, and inconsistency in how different
packages resolve the problem.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com