svn commit: r352465 - head/share/mk

[Enji Cooper]

> On Sep 18, 2019, at 07:33, Enji Cooper <yaneurabeya at gmail.com> wrote:
> 
> 
>>> On Sep 18, 2019, at 05:40, Kyle Evans <kevans at freebsd.org> wrote:
>>> 
>>> On Wed, Sep 18, 2019 at 7:34 AM Enji Cooper <yaneurabeya at gmail.com> wrote:
>>> 
>>> 
>>>> On Sep 17, 2019, at 18:58, Kyle Evans <kevans at freebsd.org> wrote:
>>>> 
>>>> Author: kevans
>>>> Date: Wed Sep 18 01:58:56 2019
>>>> New Revision: 352465
>>>> URL: https://svnweb.freebsd.org/changeset/base/352465
>>>> 
>>>> Log:
>>>> googletest: default-disable on all of MIPS for now
>>>> 
>>>> Parts of the fusefs tests trigger a bug in current versions of llvm: IR
>>>> representation of some routine for the MIPS targets is a function with a
>>>> large number of arguments. This then leads the compiler on an hour+ long
>>>> goose chase, which is OK if you build the current tree but less-so if you're
>>>> trying external toolchain or doing a universe build involving mips when it
>>>> eventually gets switched over to LLVM.
>>>> 
>>>> Better, accurate details can be found in LLVM PR43263.
>>> 
>>> Uhhhhh... why not do this in tests/sys/... instead?
>> 
>> Because there's still value in being able to easily enable these for
>> building/running the complete set of tests through standard build
>> infrastructure, but it's not worth adding a knob specifically for the
>> fusefs tests. I also prefer the communication of it being an
>> off-by-default option and easily deduced from src.conf(5) that this
>> part of the build is default-disabled on mips/mips.
> 
> Let me rephrase things a bit: is googlemock broken for all of mips, or is it just the tests? If the latter, the tests should be blacklisted for mips with a justification. If the former, I agree your method of dealing with the situation is ok, but more investigation needs to be done to see whether or not the port (in general) is broken and mark it broken if need be.

It looks like the latter case, based on the PR, and it’s a build performance issue... Is this impacting CI pipelines?

> The problem with src.opts.mk’s per-architecture options, is that it can be very heavy handed enabling/disabling features. I’m not sure that everything in there warrants disabling at that level.

My investigation suggests that the course of action was overly heavy handed. While I’m not asking for a revert, it would be really nice if whole features weren’t disabled, unless there’s an issue with the feature.

Thank you,
-Enji