CMake and mbedtls-prepare-build user guide #180
Conversation
Signed-off-by: Gilles Peskine <[email protected]>
github-project-automation
bot
moved this to In Development
in Non-roadmap pull requests
|
|
||
| #### Build in the full configuration | ||
|
|
||
| With CMake: ??? |
There was a problem hiding this comment.
Pending in Mbed-TLS/mbedtls#10038.
A build directory in the full configuration is something I do very often. It's currently broken with mbedtls-prepare-build in Mbed TLS, because mbedtls-prepare-build needs some refactoring to handle more than one config file. I expect I'll fix that soonish.
|
|
||
| ### Set and unset individual options | ||
|
|
||
| CMake doesn't have a direct way to tweak individual config options. You can write `#define` and `#undef` directives in a header file and pass that as the [user config file](#use-a-configuration-file-extension). To run `config.py`, ??? |
There was a problem hiding this comment.
A build directory with a tweaked configuration is something I do very often. I don't know how to do it with CMake.
|
|
||
| Suppose that `source1/build-foo` contains a build tree with settings that you like, and you want to set up a similar build tree in a different directory `source2`. This is common when making backports, or to share how to reproduce an issue. | ||
|
|
||
| With CMake: ??? |
There was a problem hiding this comment.
The ability to reproduce a build directory is very useful: to share how to reproduce an issue, to run the same tests on backports or a different approach to a patch, to make some tweaks such as one directory with debug symbols and one with Asan, etc. This has an impact on the design of the build directory generator: everything should end up being a single command (even if it contains &&). It doesn't work nearly as well if the reproduction steps have to include directory changes and version-dependent considerations, or worse, editing a file manually.
|
|
||
| After changing branches, or rebasing an existing branch, the build scripts may have changed. | ||
|
|
||
| With CMake, ??? |
There was a problem hiding this comment.
Re-running cmake .. in the build directory sometimes works, sometimes not. I'm not sure what to suggest other than removing and re-creating the build directory, but that requires the ability to reproduce a build directory.
|
|
||
| #### Build with all drivers | ||
|
|
||
| CMake: ??? |
There was a problem hiding this comment.
This is a known missing feature which we'll resolve eventually for the sake of all.sh.
|
|
||
| #### Enumerate build targets | ||
|
|
||
| With CMake, `make help` lists all available targets. Note that some target files must be given by their full path, while others must be given by their base name only, and some files can only be built via other targets. |
There was a problem hiding this comment.
The inconsistency and incompleteness of targets is an annoyance with our CMake scripts. Fortunately I don't think it's conceptually hard to solve, we just need some grunt work.
|
|
||
| (Note that the test programs are in the `tests` subdirectories, but the name of the build target is just the base name.) | ||
|
|
||
| With mbedtls-prepare-build, append `.run` to build and run the program. |
There was a problem hiding this comment.
make test_suite_xxx.run and the associated conveniences in the next sections are something I use a lot. They could be implemented with an auxiliary script, but it's more convenient to have them right there in the build system.
Signed-off-by: Gilles Peskine <[email protected]>
As requested, here is a description of how the kinds of builds that I typically do as an Mbed TLS maintainer, and how to do them with CMake and with mbedtls-prepare-build.
My main annoyances with CMake are:
CFLAGSin order to inject a directory early in the include path.CMakeLists.txt.