-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Q: Passing CMake variables on the command line #23
Comments
No particular reason, other than the limited development time available :) up to now, other features have simply taken precedence. I agree that it should eventually be supported, but I intend to refactor the current configuration file parser first. Currently, it lacks a good strategy to combine options from different sources: e.g. when combining a CMake For example, Conan allows you to explicitly specify how to merge options, but this is not something that TOML supports. Adding support for this would require switching to a different (or alternative) file format for local files, and would require writing a command-line parser that can deal with the configuration tree data structure. In the short term, I think adding a To make the lack of command-line options slightly more bearable, I usually use a Bash heredoc. For example: cat > ninja-debug-release.cross.toml <<- EOF
[cmake]
config = ["Debug", "Release"]
generator = "Ninja Multi-Config"
[cmake.options]
CMAKE_FIND_ROOT_PATH = "$staging/pybind11;$staging/eigen-master;$staging/casadi"
USE_GLOBAL_PYBIND11 = "On"
ALPAQA_WITH_CUTEST = "On"
EOF
python -m build -w . \
-C--cross="$PWD/ninja-debug-release.cross.toml" \
-C--cross="$staging/$host.py-build-cmake.cross.toml" Some options can also be passed to CMake using environment variables (https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html). Another possibility is to use CMake presets (https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html), where you define the options you need, and then simply pass that preset to py-build-cmake. It does require configuration files, though. |
Thanks for the explanation. A heredoc is a good solution for now! If it's OK with you, I'll leave the issue open for future reference. |
First of all: thanks for this very useful tool.
I was wondering whether it is a concsious decision (or result of a decision made in Python build flow) to only allow passing CMake overriding settings via a toml file (via -C--local=...). Oftentimes, CMake variables need to be set due to environment conditions such as the toolchain used, installation location of libraries, etc. It is a bit cumbersome to always have to create toml files for one-time passing of such settings.
It gets particularly tricky if there is a combination of different kinds of settings that we may already have separate tomls for: e.g. combining settings for finding libraries/compilers with settings such as the build type (Debug/Release/...).
The text was updated successfully, but these errors were encountered: