CMake: Dependency scope about mbedtls HOT 4 OPEN

A bit of background on this topic:

• For a very long time, nobody on the Mbed TLS development team knew CMake. Nowadays, a minority of the Mbed TLS development team knows CMake. So a lot of the CMake code is fumble-until-the-tests-pass rather than good practice.
• We tend to think of CMake as mostly for integrating in other projects that only want the library and not the tests. Our primary build system is make.
• Until Mbed TLS 3.0 release in 2021 (and even after, for anything that was backported to a 2.x long-time support branch), we kept compatible with CMake 2.8.12.2. That means we couldn't use modern CMake features.

Responding to a few points, as one of the people who don't know CMake...

compiling the shared test code into object files and linking them directly with test executables is a workaround for the mutual dependencies between the test code and the main mbed TLS libraries.

Is it? I thought it kind of just evolved that way. In the default build, code from library/* does not call any symbols from tests/*, but in some test builds, it does (when we enable callbacks, and provide them via test code). Does that impose some constraint in how cmake handles linking?

producing a separate static library for the shared test code would be a cleaner and more maintainable approach

Maybe. There's no deep reason why we aren't doing that, the current structure just grew. Originally programs/* wasn't linked against code from tests/src, but then we gradually wanted to test more configurations that required callbacks from test code, and use functions from tests/src in some programs that are under programs but intended for testing (programs/ssl/ssl_{client,server}2). We should probably restructure the directories so that all test code is under tests, and anything under programs only needs test code in some special builds that test callbacks.

Thanks for the detailed suggestions! I'll leave them for my colleagues who do know CMake.

from mbedtls.

I will need to dig into this a bit further to really properly understand it, however most things you say here seem sane on first inspection. As @gilles-peskine-arm explains, most of our cmake usage has grown rather organically, and its only quite recently that we have properly started to try and signifcantly improve it (for example using MbedTLS as a submodule properly and respecting the various settings we should be)

In regards to the question of "Is there an ongoing stream of work to refactor the test code structure and dependency management", the answer is unfortunately not at the minute, although this could be raised as a future possiblity, however we have limited resources. The quickest thing here would be to invite you to raise a PR to implement some of the ideas you have here, bearing in mind we also have to still support make, so the static library idea is probably going to be more work than you want to do. This could be raised potentially as a future piece of work, but I'm really not sure on timescales here.

from mbedtls.

Hey guys, thank you both for taking the time to respond, I now have a better idea of what went on behind the CMake 😅. I totally get the concerns with the resources and its no quick job. If I manage to squeeze some time from work, I'll definitely take a crack at this, but same on this side, not really sure on the timescale either

from mbedtls.

Would this break backward compatibility with existing projects that use our CMake files as a subdirectory or subproject?

from mbedtls.