| 1 |
cmake-utils.eclass currently defines 10 helper functions to assist in |
| 2 |
configuring packages. |
| 3 |
|
| 4 |
For example: |
| 5 |
|
| 6 |
local mycmakeargs=( |
| 7 |
$(cmake-utils_use_with foo LibFoo) |
| 8 |
) |
| 9 |
|
| 10 |
which outputs -DWITH_LibFoo=ON or OFF |
| 11 |
|
| 12 |
Most of these helpers were introduced before, and could be replaced by, |
| 13 |
usex: |
| 14 |
|
| 15 |
local mycmakeargs=( |
| 16 |
-DWITH_LibFoo=$(usex foo) |
| 17 |
) |
| 18 |
|
| 19 |
In bug #514384 it has been discussed banning many/all of these helpers |
| 20 |
in EAPI 6 and later. |
| 21 |
|
| 22 |
With usex, it's much clearer what actually get passed to cmake, reducing |
| 23 |
the chance of incorrect arguments, but $(cmake-utils_use_with foo |
| 24 |
LibFoo) is considered by some to be cleaner-looking and nicer to read |
| 25 |
than -DWITH_LibFoo=$(usex foo) |
| 26 |
|
| 27 |
The helpers also pass the same option multiple times with different |
| 28 |
capitalisation variants: |
| 29 |
|
| 30 |
$(cmake-utils_use_with foo) emits -DWITH_foo=OFF -DWITH_FOO=OFF |
| 31 |
-DWITH_Foo=OFF |
| 32 |
|
| 33 |
This makes ebuild maintenance a little bit easier, at the expense of |
| 34 |
being less "correct" and unknown configure option warnings useless |
| 35 |
|
| 36 |
The helpers themselves are listed below in order of the number of |
| 37 |
packages using them: |
| 38 |
|
| 39 |
cmake-utils_use_with 135 |
| 40 |
cmake-utils_use_enable 106 |
| 41 |
cmake-utils_use_build 89 |
| 42 |
cmake-utils_use_find_package 75 |
| 43 |
cmake-utils_use_use 37 |
| 44 |
cmake-utils_use_disable 14 |
| 45 |
cmake-utils_use_want 10 |
| 46 |
cmake-utils_use_has 8 |
| 47 |
cmake-utils_use_no 3 |
| 48 |
cmake-utils_useno 2 |
| 49 |
|
| 50 |
What do you think? |
Archives