Summary: | */*: Treewide, update non helper based CMake build dependency definitions | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Daniel Engberg <diizzy> | ||||
Component: | Ports Framework | Assignee: | Port Management Team <portmgr> | ||||
Status: | Open --- | ||||||
Severity: | Affects Some People | CC: | arrowd, diizzy, grahamperrin, jhale, makc, ports-bugs, tcberner | ||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(kde) |
||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Daniel Engberg
2023-10-15 21:32:37 UTC
Considering there are already over 50 ports which use cmake in peculiar way within their build systems, and suspecting more ports to come, I would add new argument to USES=cmake to handle this case and to hide details from the consumers. (In reply to Max Brazhnikov from comment #1) agreed, this feels like cmake:noconfigure or something :) (In reply to Max Brazhnikov from comment #1) +1 I think a cmake:noenv may be more appropriate to keep things consistent for future ports. I have yet to look at the individual ports in question, but enabling features like CMAKE_ON/OFF might be useful. Not sure how to go about this without sprinkling a bunch .if statments in cmake.mk which I'd rather avoid. (In reply to Daniel Engberg from comment #4) Daniel, I don't see how you could avoid this except shrinking away :) The principal task here is to figure out what bits of cmake.mk those ports do need (besides build dependence on cmake binary). Creating new arg for USES=cmake is not a big deal really. Can we please reinterate why simple BUILD_DEPENDS is not enough? |