Page MenuHomeFreeBSD

Add cmake options helper to disable find_package(Foo)
AbandonedPublic

Authored by tcberner on Jan 13 2019, 11:25 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 1 2024, 1:26 AM
Unknown Object (File)
Dec 21 2023, 7:42 PM
Unknown Object (File)
Oct 29 2023, 9:11 AM
Unknown Object (File)
Oct 27 2023, 10:54 AM
Unknown Object (File)
Jul 15 2023, 10:10 PM
Unknown Object (File)
Jul 9 2023, 8:37 AM
Unknown Object (File)
Jun 26 2023, 11:08 PM
Unknown Object (File)
Jun 14 2023, 6:44 PM
Subscribers

Details

Reviewers
None
Group Reviewers
portmgr
kde
O5: Ports Framework(Owns No Changed Paths)
Summary

The find_package(fooBar ...) calls in CMake can be disabled (for non-requried) package by passing CMAKE_DISABLE_FIND_PACKAGE_fooBar:BOOL=TRUE [1].

Ports that have optional dependencies that are triggered by finding a package, need to therefore pass something like

EXIV_CMAKE_BOOL_OFF=   CMAKE_DISABLE_FIND_PACKAGE_Exiv2

The proposed helper would shorten this to

EXIV_CMAKE_DISABLE_OFF=        Exiv2

It also adds the helper opt_CMAKE_DISABLE_ON -- which passes the argument if the option is on.

The diff also includes a modified devel/kio-extras to serve as an example of the usage.

[1] https://cmake.org/cmake/help/v3.13/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName.html#variable:CMAKE_DISABLE_FIND_PACKAGE_%3CPackageName%3E

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 21955
Build 21195: arc lint + arc unit

Event Timeline

I don't feel the greatest about the opt_CMAKE_DISABLE name. It implies that it disables a feature, similar to opt_CONFIGURE_ENABLE. Can it be named something that's more specific to what it does? opt_CMAKE_DISABLE_DEP, opt_CMAKE_DISABLE_PACKAGE something like that?

Also, most helpers use the opt_OPTION/opt_OPTION_OFF nomenclature. Only a few use opt_OPTION_ON/opt_OPTION_OFF and you have to read the file header to find out which is which. You might consider using the more common one. If you definitely prefer _ON and_OFF, I won't object.

I don't feel the greatest about the opt_CMAKE_DISABLE name. It implies that it disables a feature, similar to opt_CONFIGURE_ENABLE. Can it be named something that's more specific to what it does? opt_CMAKE_DISABLE_DEP, opt_CMAKE_DISABLE_PACKAGE something like that?

We could simply call it <opt>_CMAKE_DISABLE_FIND_PACKAGE_<ON/OFF> which would be the most accurate name, but, also the most tedious to write :D -- If you have no objections to the length of it, I will go with that.

Also, most helpers use the opt_OPTION/opt_OPTION_OFF nomenclature. Only a few use opt_OPTION_ON/opt_OPTION_OFF and you have to read the file header to find out which is which. You might consider using the more common one. If you definitely prefer _ON and_OFF, I won't object.

I was going off the two below -- and the behaviour felt more like the first one than the second (i.e. add the flag if only if the option is ON and the same for OFF).

# ${opt}_CMAKE_ON               When option is enabled, it will add its content to
#                               the CMAKE_ARGS.
# ${opt}_CMAKE_OFF              When option is disabled, it will add its content to
#                               the CMAKE_ARGS.
#
# ${opt}_CMAKE_BOOL             Will add to CMAKE_ARGS:
#                               Option enabled  -D${content}:BOOL=true
#                               Option disabled -D${content}:BOOL=false
# ${opt}_CMAKE_BOOL_OFF         Will add to CMAKE_ARGS:
#                               Option enabled  -D${content}:BOOL=false
#                               Option disabled -D${content}:BOOL=true

p.s. I will also add this to cmake.mk afterwards to handle the non-option cases.

Rename to CMAKE_DISABLE_FIND_ON/OFF

Rename to CMAKE_DISABLE_FIND_ON/OFF

Thanks! I like this new naming.

I think the helpfullness of a helper decreases with the number of existing helpers.
The idea of helpers is to have a few that you can remember and use without having to think about them.
This is getting to be a pretty specific edge case, and I feel the ports tree does not gain much with this.

grep'ing the ports tree for CMAKE_DISABLE_FIND_PACKAGE, I think that before adding this, it would be nice if people actually used the existing helpers, like CMAKE_BOOL_* first.

In D18833#404045, @mat wrote:

I think the helpfullness of a helper decreases with the number of existing helpers.
The idea of helpers is to have a few that you can remember and use without having to think about them.
This is getting to be a pretty specific edge case, and I feel the ports tree does not gain much with this.

grep'ing the ports tree for CMAKE_DISABLE_FIND_PACKAGE, I think that before adding this, it would be nice if people actually used the existing helpers, like CMAKE_BOOL_* first.

Probably a lot more port should use this new, as they rely on clean-room builds. But I see your point.

I'll abandon this for now... until the existing ones are better used...