cmake: setup-hooks: take structural cmakeEntries#442017
cmake: setup-hooks: take structural cmakeEntries#442017ShamrockLee wants to merge 7 commits intoNixOS:stagingfrom
cmakeEntries#442017Conversation
|
How important is being able to set :BOOL automatically? |
The flag would be more human-readable. If In the mean time, I'm also considering if we should auto-convert to Update: Just implemented the above feature. |
b124393 to
1717365
Compare
cmakeDefinitions and cmakeDefinitionTypescmakeEntries and cmakeEntryTypes
aab158f to
183cc44
Compare
183cc44 to
5a8ce02
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
RossSmyth
left a comment
There was a problem hiding this comment.
Love the idea, I'd love to see this in-tree. Unsure about the two disconnected attrset API, but it works well enough.
ba34940 to
ed8fbdf
Compare
cmakeEntries and cmakeEntryTypescmakeEntries
4e6138f to
c058a5b
Compare
c058a5b to
9f57d2d
Compare
|
Sorry for the wrong rebase. Fell free to unsubscribe. |
9f57d2d to
754b044
Compare
|
I simplified the implementation and dropped Now, CMake boolean values are expected to be either |
754b044 to
182e3ab
Compare
|
182e3ab to
dbd56f6
Compare
| @@ -16,9 +16,35 @@ You can disable this hook’s behavior by setting `configurePhase` to a custom v | |||
|
|
|||
| ### CMake Exclusive Variables {#cmake-exclusive-variables} | |||
|
|
|||
| #### `cmakeEntries` {#cmake-entries} | |||
There was a problem hiding this comment.
Is there prior art in Nixpkgs that we can refer to here, such as for another build system?
There was a problem hiding this comment.
AFAICT, this PR is the first one that implements structured flags attributes for a build system. The previous pattern is cmakeFlags and cmakeFlagsArray.
doc/hooks/cmake.section.md
Outdated
| If `cmakeEntries[WITH_FOO]` is defined and `[[ cmakeEntryTypes[WITH_FOO] == BOOL ]]`, | ||
| one can determine the condition with `[[ -n "${cmakeEntries[WITH_FOO]}" ]]`. | ||
| When prepending to the flags, however, the value will become converted to either `ON` or `OFF`. |
There was a problem hiding this comment.
Do we have a motivating example in mind where we would use this in Bash?
There was a problem hiding this comment.
Ah! This paragraph is for the previous attempt of this PR (where we have cmakeEntryTypes) and is no longer relevant.
In that design, Bash function can construct a conditional expression from a boolean cmakeEntries element using test -n or test -z, which is what we expect when passing a Nix derivation argument to the Bash builder:
if [[ -n "${cmakeEntries[ENABLE_FOO]}" ]]; then
# Do something when using -DENBLE_FOO=ON
else
# Do something when using -DENBLE_FOO=OFF
fiIn the current design, one simply assigns ON or OFF to "${cmakeEntries[ENABLE_FOO]}". { cmakeEntries.ENABLE_FOO = true; } is translated to cmakeEntries[ENABLE_FOO] when jq is available. However, we don't strongly enforce this policy, but provide tooling to accommodate other CMake-supported boolean values. For example. one can use testCMakeBool to construct a Bash conditional expression:
if testCmakeBool "${cmakeEntries[ENABLE_FOO]}"; then
# Do something when using -DENBLE_FOO=ON
else
# Do something when using -DENBLE_FOO=OFF
fitestCMakeBool will fail with non-zero exit status.
There was a problem hiding this comment.
I removed this paragraph.
dbd56f6 to
f649401
Compare
f649401 to
725c9c8
Compare
725c9c8 to
7844ff4
Compare
This PR provides structural access to the CMake flags specifying CMake variable cache entries.
If applied, we'll be able to do
Aside from
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.