> On Sep 18, 2019, at 07:33, Enji Cooper <yaneurab...@gmail.com> wrote: > > >>> On Sep 18, 2019, at 05:40, Kyle Evans <kev...@freebsd.org> wrote: >>> >>> On Wed, Sep 18, 2019 at 7:34 AM Enji Cooper <yaneurab...@gmail.com> wrote: >>> >>> >>>> On Sep 17, 2019, at 18:58, Kyle Evans <kev...@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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
