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?
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(+)
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?
