Add cmake FetchContent support

[pfeatherstone]

Suggested enhancement

It would be great if MbedTLS supported cmake's FetchContent. Ideally a project's CMakeLists.txt file could include:

include(FetchContent)

FetchContent_Declare(
        mbedtls
        GIT_REPOSITORY  https://github.com/Mbed-TLS/mbedtls.git
        GIT_TAG         v3.1.0
        GIT_PROGRESS    TRUE
        USES_TERMINAL_DOWNLOAD TRUE)

FetchContent_MakeAvailable(mbedtls)

add_executable(ExampleProgram main.cpp) #includes some MBED code

target_link_libraries(ExampleProgram MbedTLS::mbedcrypto MbedTLS::mbedx509 MbedTLS::mbedtls)

Current behaviour

CMake Error at CMakeLists.txt:27 (add_executable):
  Target "ExampleProgram" links to target "MbedTLS::mbedcrypto" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?


CMake Error at CMakeLists.txt:27 (add_executable):
  Target "ExampleProgram" links to target "MbedTLS::mbedx509" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?


CMake Error at CMakeLists.txt:27 (add_executable):
  Target "ExampleProgram" links to target "MbedTLS::mbedtls" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

Justification

This would make building from source and linking in client code seamless.

[pfeatherstone]

Currently I have to do the following:

In cmake/mbedtls.txt.in:

cmake_minimum_required(VERSION 3.21)

project(mbedtls-download)

include(ExternalProject)
include(ProcessorCount)
ProcessorCount(N)

ExternalProject_Add(
        mbedtls
        GIT_REPOSITORY          https://github.com/Mbed-TLS/mbedtls.git
        GIT_TAG                 v3.1.0
        GIT_PROGRESS            TRUE
        USES_TERMINAL_DOWNLOAD  TRUE
        USES_TERMINAL_UPDATE    TRUE
        USES_TERMINAL_CONFIGURE TRUE
        USES_TERMINAL_BUILD     TRUE
        USES_TERMINAL_INSTALL   TRUE
        SOURCE_DIR              "${CMAKE_BINARY_DIR}/mbedtls-src"
        BINARY_DIR              "${CMAKE_BINARY_DIR}/mbedtls-build"
        INSTALL_DIR             "${CMAKE_BINARY_DIR}/mbedtls-install"
        CONFIGURE_COMMAND       ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" -DENABLE_PROGRAMS=OFF -DENABLE_TESTING=OFF -DCMAKE_INSTALL_PREFIX=<INSTALL_DIR> <SOURCE_DIR>
)

In CMakeLists.txt:

configure_file(cmake/mbedtls.txt.in mbedtls-download/CMakeLists.txt)
execute_process(
        COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" .
        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/mbedtls-download)
execute_process(
        COMMAND ${CMAKE_COMMAND} --build .
        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/mbedtls-download )

list(APPEND CMAKE_PREFIX_PATH "${CMAKE_BINARY_DIR}/mbedtls-install")

find_package(MbedTLS)

add_executable(ExampleProgram main.cpp)

target_link_libraries(ExampleProgram MbedTLS::mbedcrypto MbedTLS::mbedx509 MbedTLS::mbedtls)

This is a bit of a round about way of doing things. FetchContent working would be much better. Cheers

[paul-elliott-arm]

Hi!
If you want to submit this as a PR, then we would be more than happy to review this.
Regards,
Paul.

[paul-elliott-arm]

The main issue I see here, is that it would force us to using a very new version of cmake, which may not be compatible with a lot of users requirements.

[gilles-peskine-arm]

We currently officially require CMake 3.10.2, since Mbed TLS 3.0. But we're still doing CI on platforms with CMake 3.5.1 so basic functionality has to remain compatible with this version for now.

CMake 3.10.2 is the version in Ubuntu 18.04 and SLES 15. (See this table). It's more recent than what comes out of the box on RHEL 7. It's too early to bump this requirement already.

Of course it's fine to add features that require a more recent CMake if those features are conditional on the CMake version, and don't break existing functionality on older CMake.

[pfeatherstone]

Of course it's fine to add features that require a more recent CMake if those features are conditional on the CMake version, and don't break existing functionality on older CMake.

OK cool.

Though I have to say, FetchContent only requires CMake 3.11, so it's not a major bump. In my example, I use 3.21 because that's what ships with CLion and it auto-generates a CMakeList.txt file for you.

Also, updating cmake isn't a big deal. It doesn't affect your executable in any way and you can easily download an up-to-date version either via a package manager or via the kitware website. Like, i use cmake 3.23 to build a C++98 project using a MIPS gcc cross-compiler at version 4.8. I can understand the argument for not being able to update your compiler, since you might be using third-party libraries that you can't recompile, or you are stuck with an old ABI for whatever reason, or it would upgrade the required version of libc and libstdc++, which you may not be able to do. That's fine. But updating cmake has no such consequences. So I would have no qualms with updating your minimum version to at least cmake 3.11 or higher.

[gilles-peskine-arm]

A lot of people use the build tools that come with a their operating system release. Moving from 3.10.2 to 3.11 is a huge bump since it removes compatibility with Ubuntu 18.04 and SLES 15. Ubuntu is a pretty popular platform so I don't think we'll drop it for working out of the box until 18.04 support ends. (We aren't planning to wait until extended security support, just ordinary LTS support, like we've already dropped official support for 16.04.)

[pfeatherstone]

ok fair enough

[pfeatherstone]

I don't think there is anything in cmake 3.11 that is required in the mbedtls CMakeList.txt file for Fetchcontent to work in client code. I don't think FetchContent works because of some new feature that mbedtls would have to support. Not sure, I would have to dig a bit more.