cmake presets are not usable (at leased on OSX)
ClausKlein opened this issue · 24 comments
bash-3.2$ cmake --preset=unixlike-gcc-release
Preset CMake variables:
CMAKE_BUILD_TYPE="RelWithDebInfo"
CMAKE_CXX_COMPILER="g++"
CMAKE_C_COMPILER="gcc"
CMAKE_INSTALL_PREFIX:PATH="/Users/clausklein/Workspace/cpp/cpp_boilerplate_project/out/install/unixlike-gcc-release"
-- The CXX compiler identification is AppleClang 13.1.6.13160021
-- The C compiler identification is AppleClang 13.1.6.13160021
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Developer mode is ON. For production, use `-DENABLE_DEVELOPER_MODE:BOOL=OFF`. Building the project for the developer...
-- The default CMAKE_C_STANDARD used by external targets and tools is not set yet. Using the latest supported C standard that is 17
-- /usr/local/bin/ccache found and enabled
-- Downloading conan.cmake from https://github.com/conan-io/cmake-conan
-- Conan: Adding cci remote repository (https://center.conan.io) verify ssl (True)
-- Conan: Adding bincrafters remote repository (https://bincrafters.jfrog.io/artifactory/api/conan/public-conan) verify ssl (True)
-- Single configuration build!
-- Running Conan for build type 'RelWithDebInfo'
-- Conan: checking conan executable
-- Conan: Found program /usr/local/bin/conan
-- Conan: Version found Conan version 1.47.0
-- Conan executing: /usr/local/bin/conan install /Users/clausklein/Workspace/cpp/cpp_boilerplate_project --build missing --env CC=/usr/bin/gcc --env CXX=/usr/bin/g++ --settings build_type=RelWithDebInfo --settings compiler=apple-clang --settings compiler.version=13.1 --settings compiler.libcxx=libc++ --settings compiler.cppstd=20
-- Dependency fmt already found
-- Library docopt found /Users/clausklein/.conan/data/docopt.cpp/0.6.3/_/_/package/5daf637a62aba772e1702099bde4503471cf3546/lib/libdocopt.dylib
-- Found: /Users/clausklein/.conan/data/docopt.cpp/0.6.3/_/_/package/5daf637a62aba772e1702099bde4503471cf3546/lib/libdocopt.dylib
-- Library docopt found /Users/clausklein/.conan/data/docopt.cpp/0.6.3/_/_/package/5daf637a62aba772e1702099bde4503471cf3546/lib/libdocopt.dylib
-- Found: /Users/clausklein/.conan/data/docopt.cpp/0.6.3/_/_/package/5daf637a62aba772e1702099bde4503471cf3546/lib/libdocopt.dylib
CMake Warning (dev) at CMakeLists.txt:129 (message):
Building Tests. Be sure to check out test/constexpr_tests.cpp for
constexpr testing
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/clausklein/Workspace/cpp/cpp_boilerplate_project/out/build/unixlike-gcc-release
bash-3.2$ cmake --build --preset=unixlike-gcc-release
CMake Error: No such build preset in /Users/clausklein/Workspace/cpp/cpp_boilerplate_project: "unixlike-gcc-release"
########################################################################################
bash-3.2$ ctest --build --preset=unixlike-gcc-release
CMake Error: No such test preset in /Users/clausklein/Workspace/cpp/cpp_boilerplate_project: "unixlike-gcc-release"
Available test presets:
"test-windows-msvc-debug-developer-mode" - Strict
"test-windows-msvc-release-developer-mode" - Strict
"test-windows-clang-debug" - Strict
"test-windows-clang-release" - Strict
"test-unixlike-gcc-debug" - Strict
"test-unixlike-gcc-release" - Strict
"test-unixlike-clang-debug" - Strict
"test-unixlike-clang-release" - Strict
bash-3.2$ Re: @Jason5480
something like this is missing:
"buildPresets": [
{
"name": "test",
"configurePreset": "test"
},
{
"name": "ninja-multi",
"configurePreset": "ninja-multi"
}
],
"testPresets": [
{
"name": "test",
"configurePreset": "test",
"output": {"outputOnFailure": true},
"execution": {"noTestsAction": "error", "stopOnFailure": true}
},
{
"name": "ninja-multi",
"configurePreset": "ninja-multi",
"inherits": "test"
}
]@ClausKlein the testPreset corresponding to the 'unixlike-gcc-release' configurePreset is the 'test-unixlike-gcc-release' so this is the name that should be passed to the ctest command.
something like this is missing:
If you use a multi config generator, then buildPresets are needed. But with a simple Ninja generator you do not have to pass a preset to the build stage. I have a PR that does that for "Ninja Multi-Config" generator but is still pending #19. @ClausKlein please if you have some time check if this work on OSX since I cannot check that.
@Jason5480 I can't use it to configure the build!
bash-3.2$ git status
On branch feature/ninja-multi-presets-support
Your branch is up to date with 'Nikolas/feature/ninja-multi-presets-support'.
nothing to commit, working tree clean
bash-3.2$ cmake -S . --list-presets=all
Available build presets:
"build-windows-msvc-debug" - Debug
"build-windows-msvc-release" - Release
"build-linux-gcc-debug" - Debug
"build-linux-gcc-release" - Release
"build-linux-clang-debug" - Debug
"build-linux-clang-release" - Release
Available test presets:
"test-windows-msvc-debug" - Debug
"test-windows-msvc-release" - Release
"test-linux-gcc-debug" - Debug
"test-linux-gcc-release" - Release
"test-linux-clang-debug" - Debug
"test-linux-clang-release" - Release
bash-3.2$ with a little love, is seems better:
bash-3.2$ cmake -S . --list-presets=all
Available configure presets:
"linux-gcc" - gcc
"linux-clang" - clang
Available build presets:
"build-windows-msvc-debug" - Debug
"build-windows-msvc-release" - Release
"build-linux-gcc-debug" - Debug
"build-linux-gcc-release" - Release
"build-linux-clang-debug" - Debug
"build-linux-clang-release" - Release
Available test presets:
"test-windows-msvc-debug" - Debug
"test-windows-msvc-release" - Release
"test-linux-gcc-debug" - Debug
"test-linux-gcc-release" - Release
"test-linux-clang-debug" - Debug
"test-linux-clang-release" - Release
bash-3.2$ git diffdiff --git a/CMakePresets.json b/CMakePresets.json
index a33a880..9d237b3 100644
--- a/CMakePresets.json
+++ b/CMakePresets.json
@@ -35,17 +35,7 @@
"name": "config-linux-common",
"description": "Linux settings for gcc and clang toolchains",
"hidden": true,
- "inherits": "config-common",
- "condition": {
- "type": "equals",
- "lhs": "${hostSystemName}",
- "rhs": "Linux"
- },
- "vendor": {
- "microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
- "sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
- }
- }
+ "inherits": "config-common"
},
{
"name": "windows-msvc",
@@ -231,4 +221,4 @@
"configurePreset": "linux-clang"
}
]
-}
\ No newline at end of file
+}
bash-3.2$ What is the concept behind your presets?
Missing buildDir but a sourceDir configured?
Long and different presetNames?
I would expect the same name for the same preset in config, build, and test part.
bash-3.2$ cmake -S . --preset=linux-common
CMake Error: No such preset in /Users/clausklein/Workspace/cpp/cpp_boilerplate_project: "linux-common"
Available configure presets:
"linux-gcc" - gcc
"linux-clang" - clang
bash-3.2$ cmake -S . --preset=linux-gcc
Preset CMake variables:
CMAKE_BUILD_TYPE="Debug"
CMAKE_CXX_COMPILER="g++"
CMAKE_C_COMPILER="gcc"
######################################################
Warning: in-source builds are disabled
Please create a separate build directory and run cmake from there
######################################################
CMake Error at _deps/_project_options-src/src/PreventInSourceBuilds.cmake:15 (message):
Quitting configuration
Call Stack (most recent call first):
_deps/_project_options-src/src/PreventInSourceBuilds.cmake:19 (assure_out_of_source_builds)
_deps/_project_options-src/src/Index.cmake:7 (include)
_deps/_project_options-src/Index.cmake:1 (include)
CMakeLists.txt:29 (include)
-- Configuring incomplete, errors occurred!
bash-3.2$ pwd
/Users/clausklein/Workspace/cpp/cpp_boilerplate_project
bash-3.2$ I have this on my ModernCmakeStarter:
bash-3.2$ cmake -S . --list-presets=all
Available configure presets:
"test" - Test Config
"ninja-multi" - Ninja Multi-Config
Available build presets:
"test"
"ninja-multi"
Available test presets:
"test"
"ninja-multi"
bash-3.2$
If I add this line: "binaryDir": "${sourceDir}/build", I can configure, but not build!
@Jason5480 Only if have the same names for associated presets, it works:
bash-3.2$ cmake -S . --list-presets=all
Available configure presets:
"linux-gcc" - gcc
"linux-clang" - clang
Available build presets:
"build-windows-msvc-debug" - Debug
"build-windows-msvc-release" - Release
"linux-gcc" - Debug
"linux-clang" - Debug
Available test presets:
"test-windows-msvc-debug" - Debug
"test-windows-msvc-release" - Release
"linux-gcc" - Debug
"linux-clang" - Debug
bash-3.2$ @Jason5480 I can't use it to configure the build!
bash-3.2$ git status On branch feature/ninja-multi-presets-support Your branch is up to date with 'Nikolas/feature/ninja-multi-presets-support'. nothing to commit, working tree clean bash-3.2$ cmake -S . --list-presets=all Available build presets: "build-windows-msvc-debug" - Debug "build-windows-msvc-release" - Release "build-linux-gcc-debug" - Debug "build-linux-gcc-release" - Release "build-linux-clang-debug" - Debug "build-linux-clang-release" - Release Available test presets: "test-windows-msvc-debug" - Debug "test-windows-msvc-release" - Release "test-linux-gcc-debug" - Debug "test-linux-gcc-release" - Release "test-linux-clang-debug" - Debug "test-linux-clang-release" - Release bash-3.2$
I was talking about the Jason5480:feature/presets-enchancements branch.
@Jason5480 Only if have the same names for associated presets, it works:
That is strange... your IDE should let you choose between different configure, build and test Presets. At least this is what VSCode and Visual Studio do. What IDE do you use? or you run cmake commands directly?
@Jason5480 OK, tomorrow I will hav a look
P.S. I working on console and with gvim, or Xcode
What is the concept behind your presets?
...
CMake presets are just a bundle of configuration/flags that can be passed in CMake during the configuration, build and test phases accordingly and also can be shared with the team. The changes I propose hereJason5480:feature/presets-enchancementsjust change the generator from "Ninja" to "Ninja Multi-Config". The diference with the multi-config generators is that you define the Debug/Release during the build stage and not during the configuration as you do with regular generators but this should not affect your use case.
Missing
buildDirbut asourceDirconfigured?
...
Usually, each IDE passes its own default dirs. If you run from the cli you can pass the -B -S.
Long and different
presetNames? I would expect the same name for the same preset inconfig, build,andtestpart.
...
For the multi-config generator case this cannot be done because for each configuration preset you have at least two build presets, one for the Release and one for the Debug build. The names of those build Presets should be different.
@Jason5480 OK, tomorrow I will hav a look
P.S. I working on
consoleand withgvim, orXcode
I tried those commands in Jason5480:feature/presets-enchancements and worked as expected in a Linux docker image (provided in the .devcontainer folder)
`cmake --preset=unixlike-gcc-release
cmake --build --preset=build-unixlike-gcc-release
ctest --build --preset=test-unixlike-gcc-release`
The equivalent for this repository should be
`cmake --preset=unixlike-gcc-release
cmake --build
ctest --build --preset=test-unixlike-gcc-release`
However, I did not test the later case.
@Jason5480 I can't understand your concept!
I will not use a docker image.
What are you doing exactly wenn you work on a Linux bash?
bash-3.2$ git diff
diff --git a/CMakePresets.json b/CMakePresets.json
index 631c366..8817376 100644
--- a/CMakePresets.json
+++ b/CMakePresets.json
@@ -40,6 +40,7 @@
"description": "Unix-like OS settings for gcc and clang toolchains",
"hidden": true,
"inherits": "config-common",
+ "binaryDir": "${sourceDir}/build",
"condition": {
"type": "inList",
"string": "${hostSystemName}",
@@ -47,11 +48,6 @@
"Linux",
"Darwin"
]
- },
- "vendor": {
- "microsoft.com/VisualStudioRemoteSettings/CMake/1.0": {
- "sourceDir": "$env{HOME}/.vs/$ms{projectDirName}"
- }
}
},
{
@@ -278,4 +274,4 @@
"configurePreset": "unixlike-clang"
}
]
-}
\ No newline at end of file
+}
bash-3.2$ cmake -S . --list-presets=all
CMake Error: Could not read presets from /Users/clausklein/Workspace/cpp/cpp_boilerplate_project: Invalid "configurePreset" field
bash-3.2$ pwd
/Users/clausklein/Workspace/cpp/cpp_boilerplate_project
bash-3.2$ git branch
develop
feature/modernize-cmake-project-options
feature/ninja-multi-presets-support
* feature/presets-enchancements
main
bash-3.2$ P.S. Keep it as simple as possible!
I would expect to not see any preset which is not usable on my machine.
i.e.: NO windows presets on unix like platforms!
P.S: don't forget mingw, BSD, ...
see too https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-2.html
@Jason5480 keep it simple helps!
bash-3.2$ cmake -S . --debug-output --list-presets=all
Running with debug output on.
Available configure presets:
"unixlike-gcc" - gcc
"unixlike-clang" - clang
Available build presets:
"windows-msvc-developer-debug" - Debug
"windows-msvc-developer-release" - Release
"windows-msvc-user-debug" - Debug
"windows-msvc-user-release" - Release
"windows-msvc-debug" - Debug
"windows-msvc-release" - Release
"gcc-debug" - Debug
"gcc-release" - Release
"clang-debug" - Debug
"clang-release" - Release
Available test presets:
"windows-msvc-developer-debug" - Debug
"windows-msvc-developer-release" - Release
"windows-msvc-user-debug" - Debug
"windows-msvc-user-release" - Release
"windows-msvc-debug" - Debug
"windows-msvc-release" - Release
"windows-clang-debug" - Debug
"windows-clang-release" - Release
"gcc-debug" - Debug
"gcc-release" - Release
"clang-debug" - Debug
"clang-release" - Release
bash-3.2$ @Jason5480 keep it simple helps!
Thanks, I will remove the unnecessary 'build-' and 'test-' prefixes in my PR!
Now in that case you go to the root folder of the project. Clean the previous out/build folder and run
cmake --preset=unixlike-gcc
When the project is configured build for release it like this
cmake --build --preset=gcc-release
or for debug like this
cmake --build --preset=gcc-debug
Then run the tests to make sure all went as expected.
ctest --build --preset=gcc-release
or
ctest --build --preset=gcc-debug
Let me know how that went
I would expect to not see any preset which is not usable on my machine. i.e.: NO
windowspresets onunix like platforms!
...
Hmm there is a condition that should prevent that. Well, it does try to pass the --list-presets without the =all it should return only the valid presets for your system
P.S: don't forget
mingw, BSD, ...
...
The possible combinations between 3 OSes and 4 compiler toolchains are already too many to support. Keep in mind that with every new toolchain added in the presets we should also add a CI job that verifies the correctness @ddalcino is it possible to support the aforementioned configurations in the CI soon?
see too https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-2.html
...
I will check that thanks
@ClausKlein I found that the condition ${hostSystemName} was not applied in the build and test presets... I will also add this in my PR. So, you were right about that. It is extremely helpful feedback! Thank you
@lefticus @Jason5480 I had investigated about half a day to fix this presets, prepared a MR ready to work, well tested and all is just ignored?
Please note too this CMake discussion
Please note too this
CMakediscussion
I took into account your requirement not to see the windows presents on unixlike system which is fair and logical. To prevent duplication in every condition I created two separate "windows" and "unixlike" presets where I put the conditions. Your condition for unixlike is opt-out where the existing condition was opt-in.
At this point I want to mention that we do duplicate work. We change the same files that results in many conflicts that will make it difficult to merge the changes upstream. So let me know how you want to handle this. On the other hand, it is a good thing because we both learned things we didn't know before. Please be patient, nothing is ignored as you mentioned in your post earlier. It just takes time.