svn commit: r352465 - head/share/mk

[Kyle Evans]

On Wed, Sep 18, 2019 at 9:46 AM Enji Cooper <yaneurabeya at gmail.com> wrote:
>
>
> > 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?
>

It is the latter, and I do not want to *blacklist* them because as far
as I can tell, the tests aren't necessarily broken. I want to
workaround them for default by now.

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

We do not have a lighter method for dealing with this that I can tell,
because as I said above: I do not want to blacklist them or completely
kill them off. I still want the option to build and test them, but as
I aim to switch mips over to llvm I do not want to subject CI and the
rest of the world to an extra 1.5+ hour build time for this during
tinderbox runs.

Given that it's mips, so already tier-high, and I'm one of few people
that care about it (and I only care about it for the time being), I
intend to leave it as-is since it's still a default in the rest of the
world.