Commit Graph

10 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
Ronald Cron
28ce2380b0 Add and update some .gitignore files
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
2024-06-12 15:22:26 +02:00
Dave Rodgman
16799db69a update headers
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
2023-11-02 19:47:20 +00: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
Gilles Peskine
449bd8303e Switch to the new code style
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2023-01-11 14:50:10 +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
Gilles Peskine
945b23c46f Include platform.h unconditionally: automatic part
We used to include platform.h only when MBEDTLS_PLATFORM_C was enabled, and
to define ad hoc replacements for mbedtls_xxx functions on a case-by-case
basis when MBEDTLS_PLATFORM_C was disabled. The only reason for this
complication was to allow building individual source modules without copying
platform.h. This is not something we support or recommend anymore, so get
rid of the complication: include platform.h unconditionally.

There should be no change in behavior since just including the header should
not change the behavior of a program.

This commit replaces most occurrences of conditional inclusion of
platform.h, using the following code:

```
perl -i -0777 -pe 's!#if.*\n#include "mbedtls/platform.h"\n(#else.*\n(#define (mbedtls|MBEDTLS)_.*\n|#include <(stdarg|stddef|stdio|stdlib|string|time)\.h>\n)*)?#endif.*!#include "mbedtls/platform.h"!mg' $(git grep -l '#include "mbedtls/platform.h"')
```

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2022-09-15 20:33:07 +02:00
Bence Szépkúti
c662b36af2 Replace all inclusions of config.h
Also remove preprocessor logic for MBEDTLS_CONFIG_FILE, since
build_info.h alreadyy handles it.

This commit was generated using the following script:

# ========================
#!/bin/sh
git ls-files | grep -v '^include/mbedtls/build_info\.h$' | xargs sed -b -E -i '
/^#if !?defined\(MBEDTLS_CONFIG_FILE\)/i#include "mbedtls/build_info.h"
//,/^#endif/d
'
# ========================

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
2021-06-28 09:24:07 +01: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