To use, invoke cmake with argument --preset dev-mode.
One disadvantage over ./configure --enable-dev-mode is that CMake does not provide a way to “hide” presets from users. That is, cmake --list-presets will list dev-mode, and it will also appear in cmake-gui, even though it’s not selectable there due to a bug in cmake-gui.
Solves one item in #1224.
0@@ -0,0 +1,23 @@
1+{
2+ "version": 3,
3+ "configurePresets": [
4+ {
5+ // Don't set "generator" here because developers should still be able to
6+ // select their preferred generators. As a result we're affected by CMake
7+ // bug https://gitlab.kitware.com/cmake/cmake/-/issues/23341, which means
8+ // that dev-mode is not selectable in cmake-gui. But in our case, that's
9+ // probably rather a feature than a bug.
To use, invoke
cmakewith argument--preset dev-mode.
Presets are available in CMake 3.19+ only. Should it be documented?
Presets are available in CMake 3.19+ only. Should it be documented?
I tend to say it’s not necessary. It’s for devs only and if you invoke cmake --preset on a lower cmake version, I assume it will just error out with CMake Error: Unknown argument as for other unknown arguments.
0@@ -0,0 +1,23 @@
1+{
2+ "version": 3,
That makes this preset usable only with CMake 3.21+.
And CMake 3.19 fails silently when cmake --preset dev-mode.
/CMakeUserPresets.json to the .gitignore?
Well, cmake --preset dev-mode will place the build artifacts in the source tree, which is discouraged.
There are two options to avoid such behavior:
cmake --preset dev-mode -B build or"binaryDir": "${sourceDir}/build" to the CMakePresets.json
Maybe add
/CMakeUserPresets.jsonto the.gitignore?
Done. I took the version without the leading slash because this file could in principle exist in src/ or examples/ too.
Well, cmake –preset dev-mode will place the build artifacts in the source tree, which is discouraged.
Okay, yes, this command was just intended as an example.
There are two options to avoid such behavior:
- cmake –preset dev-mode -B build or
- add “binaryDir”: “${sourceDir}/build” to the CMakePresets.json
My thinking is that, while ${sourceDir}/build is typically used, this should remain a local decision of the user/developer and not be the responsibility of the template. For example, if someone wants to maintain multiple for testing etc. … I guess the binaryDir is rather useful for automated builds, e.g, to facilitate CI configs.
58@@ -59,5 +59,7 @@ build-aux/compile
59 build-aux/test-driver
60 libsecp256k1.pc
61
62+### CMake
63+CMakeUserPresets.json
Maybe add
/CMakeUserPresets.jsonto the.gitignore?Done. I took the version without the leading slash because this file could in principle exist in
src/orexamples/too.
https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html:
CMakePresets.jsonandCMakeUserPresets.jsonlive in the project’s root directory.
My thinking is that, while
${sourceDir}/buildis typically used, this should remain a local decision of the user/developer and not be the responsibility of the template.
Command line options allow the user/developer to override a template.
My thinking is that, while
${sourceDir}/buildis typically used, this should remain a local decision of the user/developer and not be the responsibility of the template.Command line options allow the user/developer to override a template.
Would you prefer this to be added? I’m fine with either, but I still tend to think that this should not be the concern of the template. Pragmatically speaking, it doesn’t make a big difference, of course.
My thinking is that, while
${sourceDir}/buildis typically used, this should remain a local decision of the user/developer and not be the responsibility of the template.Command line options allow the user/developer to override a template.
Would you prefer this to be added? I’m fine with either, but I still tend to think that this should not be the concern of the template. Pragmatically speaking, it doesn’t make a big difference, of course.
Let’s merge it in its current state :)
Presets are available in CMake 3.19+ only. Should it be documented?
I tend to say it’s not necessary. It’s for devs only and if you invoke
cmake --preseton a lower cmake version, I assume it will just error out withCMake Error: Unknown argumentas for other unknown arguments.
I just tested with 3.16.3, and it just silently swallows the unknown option and continues. Since I would otherwise have assumed it worked, I agree it’s worth adding a quick note about required version.
To use, invoke `cmake` with argument `--preset dev-mode`.
Solves one item in #1235.
One disadvantage over `./configure --enable-dev-mode` is that CMake
does not provide a way to "hide" presets from users. That is,
`cmake --list-presets` will list dev-mode, and it will also appear
in `cmake-gui`, even though it's not selectable there due to bug
https://gitlab.kitware.com/cmake/cmake/-/issues/23341. (So in our
case, that's probably rather a feature than a bug.)
We curently use version 3 presets which require CMake 3.21+.
Unfortunately, CMake versions before 3.19 may ignore the `--preset`
argument silently. So if the preset is not picked up, make sure you
have a recent enough CMake version.
More unfortunately, we can't even spell this warning out in
CMakePresets.json because CMake does not support officially support
comments in JSON, see
- https://gitlab.kitware.com/cmake/cmake/-/issues/21858
- https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5853 .
We could use a hack hinted at in
https://gitlab.kitware.com/cmake/cmake/-/issues/21858#note_908543
but that's risky, because it could simply break for future versions,
and we probably want to use presets not only for dev mode.
This file is specifically intended for *local* CMake templates
(as opposed to CMakePresets.json).
5+ // Unfortunately, CMake versions before 3.19 may ignore the `--preset`
6+ // argument silently. So if the preset is not picked up, make sure you
7+ // have a recent enough CMake version.
8+ //
9+ // Note: JSON does not support officially, but CMake apparently
10+ // ignores lines starting with whitespace followed by "//" silently.
Digging into the CMake repository brings some discussions about that:
Urghs, thanks for doing the research here. So they first enabled comment support intentionally, then disabled it intentionally. Currently, it just works by accident.
I’m not sure how we should deal with this. Having the comments is risky because future versions may not support them. (This PR here uses presets only for dev mode, but we may add other presets, e.g., for coverage….)
It seems that CMake’s parser defeats all the hacks I could imagine or find in https://stackoverflow.com/questions/244777/can-comments-be-used-in-json. Things we could do:
// lines using grep, generating the actual .json from it. But this needs some mechanism to make sure that the file is up to date etc… All doable but seems overkill for this tiny issue.cmakeMinimumRequired field which I think is enough to document the need for CMake 3.21. A better warning should then be added to build docs (to be written :D). The comment about the missing generator thing can be in the commit message (not optimal but okayish).I lean towards dropping comments. Sad that we need to spend time on this…
I lean towards dropping comments.
Agree.
0@@ -0,0 +1,19 @@
1+{
2+ "cmakeMinimumRequired": {"major": 3, "minor": 21, "patch": 0},
3+ "version": 3,
generator entry.