If I'm counting correctly, cmake-utils declares 10 different cmake-utils_use* functions. Most of them are redundant, different only by some fancy prefix applied or implicit '!use'. Rather than helpful, this is usually more confusing since you have to make sure what a particular function does (and half of them are really confusing). If I wanted to add _native variants for multilib, that would be another 10 functions. And if you don't believe that's confusing: 1. _with, _enable, _want, _build, _use map straight -- seriously, 'cmake-utils_with foo' is so much better than 'cmake-utils_use foo WITH_FOO', 2. _find_package, _disable, _no has implicit reverse logic, 3. _find_package maps into CMAKE_DISABLE_FIND_PACKAGE, 4. _has maps into HAVE_ -- that's fun thing to do, 5. _use_use -- really friendly name. This whole mess is not worth saving a few characters. Especially that cmake doesn't come with any sanity rules or anything. So please deprecate all those fancy variants and leave us with a single, well-working, well-understood, logical function. Possibly alias it to 'cmake_use' or 'use_cmake' for easier use. use_cmake foo ENABLE_FOO [ON OFF] use_cmake !foo DISABLE_FOO [ON OFF] (love the double negatives) use_cmake !foo CMAKE_DISABLE_FIND_PACKAGE_LIBBAR multilib_native_use_cmake foo WITH_FOO
Against.
The eclass is confusing. But it makes even less sense if the deprecation causes me to do any additional work. That would be a waste of everyone's time. so it should either be a) nonfatal deprecation warnings, maybe even in repoman or b) just remove them with a newer EAPI
It could be worth evaluating the current usefulness of some of the more obscure functions, and I have no problem with exposing some cmake_use function, but I am also against blanket-removing all the helpers.
We discussed this our last meeting and decided: - We are happy to introduce a new function/alias as described upon provision of a patch - While a number of functions are indeed legacy, many were added deliberately so they will not be deprecated/removed as a group - We can consider deprecating/removing functions on a case-by-case basis taking into account usage (or lack thereof) and suitable replacement
Many of the functions were introduced before usex was available. Thoughts about eliminating the simple ones in EAPI 6 and later in favour of eg. -DWITH_LibFoo=$(usex foo)? This has the benefit of clearer ebuild behaviour, no custom functions, and less noise wrt CMAKE_WARN_UNUSED_CLI.
(In reply to Michael Palimaka (kensington) from comment #5) > Many of the functions were introduced before usex was available. Thoughts > about eliminating the simple ones in EAPI 6 and later in favour of eg. > -DWITH_LibFoo=$(usex foo)? This has the benefit of clearer ebuild behaviour, > no custom functions, and less noise wrt CMAKE_WARN_UNUSED_CLI. Please do :).
(In reply to Michał Górny from comment #6) > (In reply to Michael Palimaka (kensington) from comment #5) > > Many of the functions were introduced before usex was available. Thoughts > > about eliminating the simple ones in EAPI 6 and later in favour of eg. > > -DWITH_LibFoo=$(usex foo)? This has the benefit of clearer ebuild behaviour, > > no custom functions, and less noise wrt CMAKE_WARN_UNUSED_CLI. > > Please do :). Better not: $(cmake-utils_use_with examples) is so much nicer than -DWITH_EXAMPLES=ON READING A LOT OF CAPS CODE IRRITATES PEOPLE, REALLY :)
* should be -DWITH_EXAMPLES=$(usex examples) this way it is even worse...
(In reply to Andrew Savchenko from comment #7) > Better not: > $(cmake-utils_use_with examples) > is so much nicer than > -DWITH_EXAMPLES=ON How it looks is subjective, but usex is more practical for a few reasons. 1. It's much clearer what actually gets passed to cmake and there's less chance for broken packages as a result. 2. A single option gets passed to cmake, instead of the same option multiple times with diffrent capitalisation variants 3. Smaller API makes eclass easier to use and maintain
(In reply to Michael Palimaka (kensington) from comment #9) ignoring the generalities, the cmake eclasses and util functions make it a lot easier for people who aren't familiar with cmake to write ebuilds. imo it makes maintenance easier, and i agree with Andrew's style points.
You all seem to be ignorant about probably the most important hidden feature of those functions: they generate different-case permutations of CMake variables: $(cmake-utils_use_with acl) $(cmake-utils_use_with fam) will emit: -DWITH_acl=OFF -DWITH_ACL=OFF -DWITH_Acl=OFF -DWITH_fam=OFF -DWITH_FAM=OFF -DWITH_Fam=OFF Over the years we found various upstreams playing with CMake option renames often that were breaking our buildsystems in subtle ways. scarabeus got fed up with that eventually and added code to emit alllowercase/UPPERCASE/Capitalized variants. One can say - "hey, but that's ebuild bug, ebuild should follow CMakeLists.txt". I will say - yes that ebuild bug, but go ahead hunt down all small case changes in hundreds of KDE packages) every time new version is released. Those functions are not going anywhere. Over my dead-GPG-keys. Sorry.
(In reply to Maciej Mrozowski from comment #11) i don't think "you all" means what you think it means ... i'm fully aware what the funcs expand into, as is Michael (comment #9). also, not everyone who has commented in this bug is pro removing the functions.
(In reply to Maciej Mrozowski from comment #11) > You all seem to be ignorant about probably the most important hidden feature > of those functions: they generate different-case permutations of CMake > variables: If you read the previous comments, you would know this is not the case. If you followed previous bug history, you'd also know that feature is considered by some to be a bug. > > $(cmake-utils_use_with acl) > $(cmake-utils_use_with fam) > > will emit: > > -DWITH_acl=OFF -DWITH_ACL=OFF -DWITH_Acl=OFF > -DWITH_fam=OFF -DWITH_FAM=OFF -DWITH_Fam=OFF > > Over the years we found various upstreams playing with CMake option renames > often that were breaking our buildsystems in subtle ways. scarabeus got fed > up with that eventually and added code to emit > alllowercase/UPPERCASE/Capitalized variants. > > One can say - "hey, but that's ebuild bug, ebuild should follow > CMakeLists.txt". > I will say - yes that ebuild bug, but go ahead hunt down all small case > changes in hundreds of KDE packages) every time new version is released. This has not been the case for a long time, if you followed what is happening with KDE and other cmake consumers in general. > Those functions are not going anywhere. Over my dead-GPG-keys. Sorry. It's not your (or any other single person's) decision.
(In reply to Michael Palimaka (kensington) from comment #13) nor is unanimous agreement required, and in such cases, the decision is left up to the maintainers (KDE team in this case)
With my lead hat on: We will discuss/vote again on this topic with EAPI 6 finalization.
Thanks, fixed in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9116b1aebc819a10410960cbb4931aa5e399af1
Not resolved completely, change in docs is missing.
(In reply to Jan Chren (rindeal) from comment #17) > Not resolved completely, change in docs is missing. Which docs?
Those comments above functions from which https://devmanual.gentoo.org/eclass-reference is generated.
Just FYI, I already noticed bump request (atatched ebuild) on my bugs, done by Gentoo developers, with broken CMake case. So it's apparently not common knowledge what does it mean to convert ebuilds inheriting cmake-utils to EAPI-6...
