Re: pkg/51766: Enabling cwrappers breaks builds on FreeBSD 11

[rodent%NetBSD.org@localhost]

On Wed, Jan 04, 2017 at 09:26:28PM +0100, Joerg Sonnenberger wrote:
> On Wed, Jan 04, 2017 at 05:30:01PM +0000, rodent%NetBSD.org@localhost wrote:
> > The following reply was made to PR pkg/51766; it has been noted by GNATS.
> > 
> > From: rodent%NetBSD.org@localhost
> > To: Joerg Sonnenberger <joerg%bec.de@localhost>
> > Cc: gnats-bugs%NetBSD.org@localhost, joerg%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost,
> > 	pkgsrc-bugs%netbsd.org@localhost
> > Subject: Re: pkg/51766: Enabling cwrappers breaks builds on FreeBSD 11
> > Date: Wed, 4 Jan 2017 12:26:19 -0500
> > 
> >  On Wed, Jan 04, 2017 at 05:12:03PM +0100, Joerg Sonnenberger wrote:
> >  > On Wed, Jan 04, 2017 at 03:25:01PM +0000, diro%nixsyspaus.org@localhost wrote:
> >  > >  Attached. Bootstrap was ran using this mk.conf file like:
> >  > >  
> >  > >  ./bootstrap --mk-fragment=/usr/pkg/etc/mk.conf --pkgdbdir=/var/db/pkg
> >  > >  
> >  > >  The mk.conf and mk.conf.example generated by bootstrap have ABI, CC, CXX, CPP,
> >  > >  CLANGBASE, and other variables set as well, which aren't present in the
> >  > >  attached file. However, with USE_CWRAPPERS=no it doesn't make a difference,
> >  > >  because the build works with that variable set.
> >  > 
> >  > So does it work with the default mk.conf generated by bootstrap?
> >  
> >  Yes, it does. However, why does the previously attached mk.conf work with
> >  USE_CWRAPPERS=no yet fail when it's removed. Does the cwrappers package
> >  require all those variables to be set in mk.conf for it to work at all?
> 
> It is stricter about how it calls the compiler. CLANGBASE is likely the
> culprit, without it the detection of clang can silently fail and result
> in PKG_CC and friends being set to false. Just because something works
> by accident doesn't mean it is correct.
> 
> Joerg

All right, thanks for clarifying. If we're going to make this kind of stuff
default, it would be ideal to have this sort of information outlined in
doc/pkgsrc.txt. Else, we get "surprises" upon updating and that's not ideal.
Now, there's not one word about CWRAPPERS in the doc, which is strange if it's
going to be a default setting.

Running into situations like this and PKG_DBDIR with bootstrap can be avoided
by thinking through more use cases. For example, this was done by blowing away
the entire /usr/pkg and /var/db/pkg*, copying pkgchk.conf and mk.conf in
place, unpacking a new quarterly tarball, bootstrapping, building pkg_chk, and
proceeding to rebuild all the packages on the machine. If there is a more
*reliable* method of updating with less surprises for people who build from
source, perhaps the docs could use an update for that as well.

The above method sounds like a lot of steps, except it can be automated with
ansible. Best case scenario, after updating the OS, we run ansible, and
everything is like new and magic again with fresh packages and the old
application configurations, and services running happily. When you have many
machines in different places, this type of automation saves a lot of time.