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!