Re: options for forcing use of GCC

On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote:
> On Apr 28, 2014, at 9:52 AM, Kevin Oberman <rkoberman_at_gmail.com> wrote:
> 
> > On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore <ian_at_freebsd.org> wrote:
> > 
> >> On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote:
> >>> On 4/28/14, 8:05 PM, Ian Lepore wrote:
> >>>> On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote:
> >>>>> On 4/28/14, 12:30 AM, Ian Lepore wrote:
> >>>>>>  WITH_GCC=yes \
> >>>>>>  WITH_GNUCXX=yes \
> >>>>>>  WITHOUT_CLANG=yes \
> >>>>>>  WITHOUT_CLANG_IS_CC=yes \
> >>>>> forgot to ask.. is this in /etc/make.conf?
> >>>>> or elsewhere?
> >>>> Actually in our build system we build in a chroot, and we inject those
> >>>> args into the environment during the builds so that we can have
> >>>> different options for building world versus cross-world within the
> >>>> chroot, but I think the more-normal place would be make.conf.
> >>> 
> >>> we also use a combination of environment and make.conf in a chroot.
> >>> though people sometimes talk about a src.conf (or is that src.mk?) but
> >>> I haven't found that one yet.
> >>>> 
> >>>> -- Ian
> >>>> 
> >>>> 
> >>>> 
> >> 
> >> In theory, /etc/make.conf affects all builds you do -- world, kernel,
> >> ports, your own apps, everything -- whereas /etc/src.conf affects only
> >> kernel and world.  I've heard it said that the reality falls short of
> >> that and src.conf settings inappropriately leak into ports builds.
> 
> That’s bogus. Port builds define _WITHOUT_SRCCONF which precludes not
> only including /etc/src.conf, but also disables the while WITH/WITHOUT_FOO
> mechanism from converting those options into MK_FOO options.
> 
> > I have also heard this, but a grep of ports/Mk finds no matches to
> > src\.conf, so this appears to not be the case.
> 
> Ports specifically goes out of its way to make sure this doesn’t happen. Perhaps
> it isn’t going out of its way far enough?
> 
> > It should not be as the whole purpose of src.conf was to have a make
> > configuration that would be used to build the system, but not other things.
> > make.conf already provided for that.
> 
> If someone can show me a specific, verifiable leak, I’ll look into it. Vague
> rumors about possible issues that may have existed once upon a time
> aren’t fruitful to chase.
> 

You've known me long enough to know that the "Vague rumors..." sentence
doesn't describe the way I operate.  I was vague on the fine details,
but I remember an email thread where it was specifically shown that the
contents of src.conf were affecting ports builds.  I just tracked it
down [1] and about midway through that thread it materialized that some
ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the
inappropriate inclusion of src.conf into a port build.

So I figured I'd do a quick look for ports makefiles that are including
bsd.[lib|prog|subdir].mk :

revolution > find . -name Make* | xargs grep bsd.*mk | \
  grep -v bsd.port| grep -E "lib.mk|prog.mk|subdir.mk" | wc -l
      66

That's probably not a perfect search, but it looks like there are a few
ports that may be perturbed by src.conf settings, plus as was revealed
in that thread, if you use /usr/share/mk/bsd.*.mk for your own software
(as we do at $work) then your own builds are also affected by src.conf.

I quite agree with the sentiments expressed in that thread that the
genesis of the problem is the opt-out nature of src.conf.  If it had
been designed as an opt-in feature with a handful of /usr/src makefiles
opting in as-needed, maybe the situation would be cleaner today.  Then
again, maybe that leads to other problems -- it's always easy to say
"the right thing to do would have been..." when you haven't fought your
way through actually making your plan work.

[1]
http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039709.html

-- Ian