Commit Graph

5 Commits

Author SHA1 Message Date
Ronald Cron
b7d0e52e16 cmake: Rename mbedcrypto target to tfpsacrypto
Rename mbedcrypto target to tfpsacrypto and
prefix all cmake related variables with
tfpsacrypto instead of mbedcrypto.

Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2024-11-14 09:28:27 +01:00
David Horstmann
6c979856c3 Remove generated files in all cmake_as_x tests
Signed-off-by: David Horstmann <david.horstmann@arm.com>
2023-09-28 11:30:43 +01:00
Paul Elliott
a722d0a415 Update CMake minimum version(s) to match main CMakeLists.txt
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
2023-09-12 16:42:14 +01:00
Issam E. Maghni
760f3a0a48 Install CMake files in MbedTLS dir
Right now, CMake files are installed in <prefix>/cmake. That being said,
it gets easily bloated, and the standard is to use a directory with the
same name as the project.

I discovered this issue with this "bug":
https://github.com/termux/termux-packages/issues/12416
The issue's author claimed that MbedTLS's files were not installed in
the lib directory. But the patch applied by termux team broke CMake's
search of MbedTLS config files. So I wanted to upstream the real fix
here instead.

Here are some examples of projects using directories:
 - https://github.com/xiph/flac/blob/1.4.2/CMakeLists.txt#L239
 - https://gitlab.freedesktop.org/dbus/dbus/-/blob/dbus-1.15.2/CMakeLists.txt#L675
 - https://github.com/catchorg/Catch2/blob/v3.2.0/CMakeLists.txt#L62
 - https://github.com/capnproto/capnproto/blob/v0.10.2/c++/CMakeLists.txt#L162

Signed-off-by: Issam E. Maghni <issam.e.maghni@mailbox.org>
2022-12-04 03:00:38 +00:00
Chris Kay
d259e347e6 Add CMake package config file
This change enables automatic detection and consumption of Mbed TLS
library targets from within other CMake projects. By generating an
`MbedTLSConfig.cmake` file, consuming projects receive a more complete
view of these targets, allowing them to be used as dependencies which
properly inherit the transitive dependencies of the libraries.

This is fairly fragile, as it seems Mbed TLS's libraries do not appear
to properly model their dependencies on other targets, including
third-party dependencies. It is, however, sufficient for building and
linking the compiled Mbed TLS libraries when there are no third-party
dependencies involved. Further work is needed for more complex
use-cases, but this will likely meet the needs of most projects.

Resolves #298. Probably useful for #2857.

Signed-off-by: Chris Kay <chris.kay@arm.com>
2021-06-04 16:02:48 +01:00