Good point! But with the added wrinkle that it isn't enough to install the alternative config file. Unless you pass -DMBEDTLS_CONFIG_FILE when compiling any file that includes an mbedtls header, the default config file would still be used.

I'm not sure how to fully resolve this. MBEDTLS_CONFIG_FILE contains a path that's passed to the compiler while building Mbed TLS itself. This can be an absolute path, and often is, to make it easier to build files in subsubdirectories. But after installation, it must not be a relative path.

I wonder what is the right way to resolve this. Inject the setting into the installed mbedtls_config.h? How do we determine the correct post-installation path?

Note that this applies to MBEDTLS_USER_CONFIG_FILE as well. And TF_PSA_CRYPTO_CONFIG_FILE and TF_PSA_CRYPTO_USER_CONFIG_FILE in TF-PSA-Crypto. (In 3.6, we have the CMake variables to change mbedtls_config.h, but for changing crypto_config.h, the options only exist with the C preprocessor, not with CMake as well.)

(I'm not sure whether to label this “bug” or “enhancement”. We mostly intended this for the convenience of developer builds and test scripts, and I guess we just didn't think about usage outside the development team. But once the possibility is there, it is natural to expect it to work together with installation.)

To be more specific, here is the use case:

1. user builds mbedtls with -DMBEDTLS_CONFIG_FILE then make
2. user installs mbedtls with make install
3. user copies the installed static libraries and the include/ subtree into some other project A (or imports these as a cmake package, or whatever)
4. user builds project A, which includes some mbedtls headers from the install, which recursively include the specific file include/mbedtls/mbedtls_config.h, and this configuration absolutely does not match the corresponding binaries

Notice that the user has no option to set -DMBEDTLS_CONFIG_FILE in project A, because there is no such flag in project A. It is some completely other project that is using mbedtls. As a specific example, when I did this after enabling MBEDTLS_X509_TRUSTED_CERTIFICATE_CALLBACK, my static mbedtls libs had the callback enabled. But because the original mbedtls_config.h was installed alongside that static lib, it still had MBEDTLS_X509_TRUSTED_CERTIFICATE_CALLBACK commented out, and my build failed with an undefined symbol on the callback.

This is a bug, not an enhancement request. When cmake builds mbedtls with a certain configuration C, it is imperative that the installed mbedtls_config.h exactly matches the configuration C as it was built. Otherwise dependent projects will absolutely and certainly fail to build.

When cmake builds mbedtls with a certain configuration C, it is imperative that the installed mbedtls_config.h exactly matches the configuration C as it was built.

This is only the case when you don't pass compiler flags that change the meaning of the header files. And passing -DMBEDTLS_CONFIG_FILE=… to the compiler (i.e. in CFLAGS) changes the meaning of the header files. So would, for example, passing -DMBEDTLS_X509_TRUSTED_CERTIFICATE_CALLBACK directly in CFLAGS.

If you pass -DMBEDTLS_X509_TRUSTED_CERTIFICATE_CALLBACK in CFLAGS when compiling Mbed TLS, you must also pass it whenever you compile something that uses Mbed TLS. The same applies if you pass -DMBEDTLS_CONFIG_FILE=… in CFLAGS.

There is also a CMake variable with the name MBEDTLS_CONFIG_FILE. What it does under the hood is to add -DMBEDTLS_CONFIG_FILE=… to CFLAGS, with some CMake magic (I think) to ensure that the file path will be correct relative to the build directory. I'm not sure how that can be communicated after installation.

Using both MBEDTLS_CONFIG_FILE and install in the same build was not specifically intended to work when we added MBEDTLS_CONFIG_FILE as a CMake variable. So it's more like a missing feature, and one that to me looks difficult to implement.

I do agree that the current situation is not good though. But if we don't find a better solution, we may resolve it by throwing an error on make install if MBEDTLS_CONFIG_FILE is defined.

By the way, we don't have a lot of CMake expertise (although we're learning). If you (or anyone) knows how to do this right, we would welcome a patch.

What would be the use case for building mbedtls with cmake and not using the install phase of the build? It seems fairly hypothetical.

We're not willing to include mbedtls defines in all downstream projects, so we are simply adding a post-install step to clobber the incompatible mbedtls_config.h with one that matches the binaries.

I think it is just the case that in include/CMakeLists.txt if the CMake MBEDTLS_CONFIG_FILE variable is defined we should install in include/mbedtls the file whose path is given by MBEDTLS_CONFIG_FILE instead of the default one.

I think it is just the case that in include/CMakeLists.txt if the CMake MBEDTLS_CONFIG_FILE variable is defined we should install in include/mbedtls the file whose path is given by MBEDTLS_CONFIG_FILE instead of the default one.

Simply to say, the file given by MBEDTLS_CONFIG_FILE should be copied to include/mbedtls/mbedtls_config.h.

Simply to say, the file given by MBEDTLS_CONFIG_FILE should be copied to include/mbedtls/mbedtls_config.h.

Only if -DMBEDTLS_CONFIG_FILE is passed when building Mbed TLS, but not passed when building code that uses Mbed TLS. Otherwise #if defined(MBEDTLS_CONFIG_FILE) #include MBEDTLS_CONFIG_FILE will trigger when building the application.

Same concern with MBEDTLS_USER_CONFIG_FILE, which may be defined in mbedtls_config.h or the alternative MBEDTLS_CONFIG_FILE. Whose responsibility is it to ensure that the file is installed at a location that's correct for the include path?

Are these preprocessor macros fundamentally incompatible with installation?

Otherwise #if defined(MBEDTLS_CONFIG_FILE) #include MBEDTLS_CONFIG_FILE will trigger when building the application.

From the description, the suppilied CMake file build creates the library. Then the library is installed - to be used later without this library build script.
Would it be a library's fault if user's build scenario again declared an alternative configuration file? This should be user's responsibility.

Are these preprocessor macros fundamentally incompatible with installation?

Unlimited number of ways to cause a failure could be invented.
Perhaps it should be clearly specified what install script would do in case of defining alternative configuration files (after the library split - plural could be applicable).

By the way, there was my feature request to provide a standard place for user-defined files. If alternative configuration was using other (non-standard) locations, the files could be copied to the standard place. At least, this would provide a copy of original files.