| Summary: | flag-o-matic.eclass: test-flags-* docs do not describe output | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Eclasses | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | gentoo |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Functions in BASH can only RETURN number (integer), not string, but they can OUTPUT string.
Descriptions of test-flags-CC etc. are correct and they mean that it is possible to use these functions in this way:
if test-flags-CC -flag1 -flag2; then
....
else
....
fi
There are test-flag-* and test-flags-* variants of these functions.
test-flag-* can be actually called with multiple arguments.
test-flag-* returns true only if all specified flags are supported, and currently does not output anything.
test-flags-* returns true if at least one of specified flags is supported, and outputs only these flags which are supported (some subset of flags passed to function).
If current behavior is to remain, then descriptions of test-flags-*, but not test-flag-*, can be extended:
# @FUNCTION: test-flags-CC
# @USAGE: <flags>
# @DESCRIPTION:
# Returns shell true if <flags> are supported by the C compiler, else returns shell false.
# Outputs supported flags.
I know. Let me rephrase: "people may be relying on undocumented behaviour of functions". use() has verbose usev() equivalent. Maybe it would be cleaner to have 4 groups of functions. E.g.: test-flags-all-* (e.g. test-flags-all-CC) test-flags-verbose-all-* (e.g. test-flags-verbose-all-CC) test-flags-any-* (e.g. test-flags-any-CC) test-flags-verbose-any-* (e.g. test-flags-verbose-any-CC) |
Docs say: ``` test-flags-CC <flags> Returns shell true if <flags> are supported by the C compiler, else returns shell false. test-flags-CXX <flags> Returns shell true if <flags> are supported by the C++ compiler, else returns shell false. test-flags-F77 <flags> Returns shell true if <flags> are supported by the Fortran 77 compiler, else returns shell false. test-flags-FC <flags> Returns shell true if <flags> are supported by the Fortran 90 compiler, else returns shell false. test-flags-CCLD <flags> Returns shell true if <flags> are supported by the C compiler and default linker, else returns shell false. test-flags <flags> Short-hand that should hopefully work for both C and C++ compiler, but its really only present due to the append-flags() abomination. ``` But they actually return the flags tested: ``` $ grep -rsin "test-flags-" dev-lang/cfortran/cfortran-20110621.ebuild:42: use sparc && append-fflags $(test-flags-FC -fno-store-merging -fno-tree-slp-vectorize) # bug 818400 dev-lang/cfortran/cfortran-20210827.ebuild:43: use sparc && append-fflags $(test-flags-FC -fno-store-merging -fno-tree-slp-vectorize) # bug 818400 dev-lang/c-intercal/c-intercal-31.0.ebuild:51: append-cflags $(test-flags-CC -fno-toplevel-reorder) #722862 dev-lang/python/python-3.10.6_p2.ebuild:163: append-cflags $(test-flags-CC -ffat-lto-objects) dev-lang/python/python-3.8.13_p6.ebuild:149: append-cflags $(test-flags-CC -ffat-lto-objects) dev-lang/python/python-3.9.13_p4.ebuild:159: append-cflags $(test-flags-CC -ffat-lto-objects) dev-lang/python/python-3.11.0_rc1.ebuild:150: append-cflags $(test-flags-CC -ffat-lto-objects) ``` We even document this usage as an example in the eclass: ``` # @FUNCTION: append-cflags # @USAGE: <flags> # @DESCRIPTION: # Add extra <flags> to the current CFLAGS. If a flag might not be supported # with different compilers (or versions), then use test-flags-CC like so: # @CODE # append-cflags $(test-flags-CC -funky-flag) # @CODE [...] ``` We should just fix the docs for test-flag(s?)* to mention it returns the relevant flags.