Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 778191

Summary: flag-o-matic.eclass: add support for filtering MAKEOPTS
Product: Gentoo Linux Reporter: Sam James <sam>
Component: EclassesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: CONFIRMED ---    
Severity: normal CC: gentoo
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=302399
https://bugs.gentoo.org/show_bug.cgi?id=654000
Whiteboard:
Package list:
Runtime testing required: ---

Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-03-25 16:33:48 UTC
Not all make implementations support all possible arguments, such as bmake and --load-average (-l).

This was discovered when fixing hikari to use emake with ${MAKE}=bmake in the ebuild rather than calling bmake directly: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=893ef30a570d5d1e202e6b9e007eda4bec663b67.

Could flag-o-matic support filtering MAKEOPTS here?
Comment 1 Larry the Git Cow gentoo-dev 2021-03-25 17:03:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=39f7155b659b65a406fc405fffbd417a66a1d3f5

commit 39f7155b659b65a406fc405fffbd417a66a1d3f5
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-03-25 17:02:05 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-03-25 17:02:05 +0000

    gui-wm/hikari: add MAKEOPTS filtering hack for now
    
    We need to hack out --load-average (-l) from MAKEOPTS
    for now until we have a better way (e.g. flag-o-matic.eclass)
    to filter out options from MAKEOPTS for implementations
    which don't support it, like bmake.
    
    Thanks-to: ggabriel
    Bug: https://bugs.gentoo.org/778191
    Signed-off-by: Sam James <sam@gentoo.org>

 gui-wm/hikari/hikari-2.2.2-r1.ebuild | 5 +++++
 1 file changed, 5 insertions(+)
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2021-03-25 20:06:10 UTC
flag-o-matic.eclass is mostly about toolchain flags (CFLAGS/LDFLAGS). I would say $MAKE is outside the scope of it. A separate eclass might be fine, but I also have thoughts on it:

PMS says you can override both $MAKE and $MAKEOPTS. I'd say it's up to the user to make both match.

In your case ebuild does not allow passing $MAKE and override it with MAKE=bmake (and as a result have to amend $MAKEOPTS).

The simple solution would be to ignore MAKEOPTS as well and possibly only provide -j $(makeopts_jobs). Is it not enough?

Why I don't like flag filtering in general: Toolchain packages use filter-flags equivalent for similar use case (bootstrap compiler frequently does not match, $CC, cross-compiling requires host and target $CFLAGS, etc). Filtering breaks under various corner cases: option negation does not work correctly, some options are passed through that should not have and the other way around, flag filtering does not introspect the overriding tool enough.

Implementing a reasonable command parser is hard. Adding a few common hacks might be OK.

This comes down to what you would expect such a $MAKEOPTS filter to do. Should it filter down to a set of known safe options? Should it filter away GNU-make-isms? Should it filter those out even when MAKE=GNU make (but set by user)?

There is a big space of ambiguity. How do you see the end state?