Requirements for the build system

[gilles-peskine-arm]

Write a requirements document for the build system.

Consider both the perspective of users and the perspective of maintainers.

Mailing list thread: https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmware.org/thread/3HMNORCDGREUPE7XSTD2CKXFRZJXL36O/

---

Reasons why we're thinking about the build system:

• TF-PSA-Crypto needs one. What will it be?
• We don't really like any of the existing build systems in Mbed TLS:
  • GNU makefiles: complex, few people on the team understand it, doesn't have correct dependencies, doesn't do out-of-tree builds.
  • CMake files: complex, few people on the team understand it, slow, inflexible, doesn't support many of the non-end-user targets.
  • Visual Studio solutions: few people on the team understand it, only for Visual Studio, doesn't support many of the non-end-user targets.

---

Our primary high-level requirements:

• Needs to be able to be included in a CMake project, because those are common in our ecosystem.
• No reliance on complex external tools. We're ok with CMake but would not use automake and friends.
• Suitable for users and maintainers and CI. E.g. can have multiple build trees, doesn't rebuild the whole project each time, can do all kinds of weird test builds.
• Easy to maintain. Can we have a single system? This would have to be CMake.

[chad-earthscope]

First, I really appreciate finding mbedtls; open, non-viral licensed, trusted, portable, embeddable TLS libraries are few and far between. Especially ones that are actively and professionally maintained. Thank you.

My use case is is to include mbedtls in other open source client library and server implementations that are generally expected to be buildable on unix/Linux/macOS/BSDs and Windows. Therefore I do not have a "platform" or a "application" (for the library case) , or requirements for security of my own.

Regarding build system requirements, I usually speak the lowest common denominator for all systems. For the Unix-like cases the gnu makesfiles are great and match my projects cases, for which cmake would be an anomalous new dependency (and not often installed by default on systems, so a significant barrier for users that are not sysadmins). For Windows I am currently trying to figure out a method for a clean build that runs cmake from NMake, which is what my projects are using and I have one major use cases for a system that is all NMake. This is non-ideal combination. At least in windows if you have NMake installed you usually have cmake also. My ideal scenario is that you provide NMake makefiles as well, though I understand this is unlikely.

Some additional feedback based on my use cases: Regarding the build config and as a non TLS or security expert, I do not want to make decisions about detailed features. I would much rather let you all decide what reasonable defaults should be according to best practice, etc. So direct, easy ways to build TLS+crypto+509 libraries with no extras or uncommon dependencies, and sane defaults for common client and server use cases would be great.

A build system that requires python, perl, or even cmake, which are not always present, is a major dependency/barrier for systems that do have them, and therefore effecting portability. I imagine this might be one of the reasons to focus on cmake as the one solution. Unfortunately cmake is a pain for including in projects that are not already using cmake.

Thanks again for this work!

[mschulz-at-hilscher]

We build mbedtls for our embedded systems and do not use any of the build mechanisms provided by mbedtls. Instead, we just take the C files and integrate them in our build environment which is WAF (https://waf.io/). It it nice when building for multiple tarets at once or different variants for the same platform with different compile flags. I do not want to enforce any build system, but it shall still be possible to simply build with any build system by taking the C files. If files are generated, there should be a consistent mechanism that can easily be ported to other build systems and build environments, for example, by using Python for file generation.

[chad-earthscope]

We build mbedtls for our embedded systems and do not use any of the build mechanisms provided by mbedtls

Thank you @mschulz-at-hilscher! That was extremely useful for me to try. I am now using mbedtls library sources directly and everything builds and runs on linux, macOS, and Windows without so much as a compiler warning, amazing. The ability to do this is preferred over the incorporation of a different build system.

Also, I now realize this issue was not actually about mbedtls. My apologies for the noise. Edit: or I guess it is about mbedtls 4, and I'm just confused...