| 1 |
Hello, |
| 2 |
|
| 3 |
General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6 unless |
| 4 |
you know what you are doing (you are fully aware of eclass behaviour removed |
| 5 |
with https://bugs.gentoo.org/show_bug.cgi?id=514384). |
| 6 |
|
| 7 |
Background: |
| 8 |
|
| 9 |
Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake |
| 10 |
variable case changes done by upstream. |
| 11 |
This feature was explicitly removed with |
| 12 |
https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was |
| 13 |
proposed. |
| 14 |
It opened new area of possible ebuild regression bugs when switching to EAPI-6 |
| 15 |
for ebuilds inheriting cmake-utils.eclass. |
| 16 |
|
| 17 |
Unfortunately there is common misconception, also among developers, that it's |
| 18 |
sufficient to simply replace "${cmake-utils_use_with foo)" with "-DWITH_foo=ON" |
| 19 |
etc. |
| 20 |
This is MOST OF THE TIME not the case. |
| 21 |
When converting cmake-utils ebuild to EAPI>=6, one needs to consult |
| 22 |
CMakeLists.txt wrt case each variable is written with since CMake is case- |
| 23 |
sensitive and WITH_FOO != WITH_foo != WITH_Foo. |
| 24 |
|
| 25 |
Proposal: |
| 26 |
|
| 27 |
CMake allows warning about unused CMake variables passed by CLI. Since this is |
| 28 |
how Gentoo passes ebuild configuration options, it's proposed to enable this |
| 29 |
feature. |
| 30 |
Unfortunately it won't fail compilation but at least it gives a chance to spot |
| 31 |
case mismatch when reading build output. |
| 32 |
|
| 33 |
Future thoughts: |
| 34 |
|
| 35 |
For better damage control it's technically possible to extend configure phase |
| 36 |
of cmake-utuls eclass to check mycmakeargs against parsed package buildsystem |
| 37 |
but this might not be very reliable. |
| 38 |
|
| 39 |
regards |
| 40 |
MM |
Archives