Re: options for forcing use of GCC

On Apr 28, 2014, at 11:38 AM, Ian Lepore <ian_at_FreeBSD.org> wrote:

> 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.

Sorry that I misconstrued the sentiment you were expressing. My bad.

> 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

Ah, it is affecting the building of the actual ports, not the bsd.ports.mk system.
That’s the kind of detail that’s good to know. In the near future, that won’t
happen, unless the port’s controlling Makefile.

> 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.

It is sufficient for me to get the issue. I’d mistakenly thought it was affecting
ports build orchestration, but it is affecting anything that causes bsd.own.mk
to be included using our make(1). Since I thought it was a reference to the
former I was quite confused. Now that I know it is to the latter, I’m no longer
confused.

> 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.

I agree as well…

Which is why I have been moving the options into their own file and
separating them into different categories. In my tree I have a src.opts.mk
file now, which is easy enough to do from where we are in the tree.
The trouble is untangling it so that we can set it free from the bsd.*.mk
files and have it only influence the /usr/src build without breaking other
currently useful features of the /usr/src build. My plan is to move inclusion
of src.conf into that file once I work those kinks out. Once that happens,
then only make.conf will affect the subordinate builds that opt to use the
bsd.*.mk. I’ve been reluctant to commit this next step because to not break
things, I’d have to install src.opts.mk, which could cause issues down the
road if I find a way to not install it… This should move us fully to an opt-in
design….

Warner

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