Conventions for Linking Implicit Dependencies of an embedded Multi-Language Static Library?

Code
1

I wanted to ask if there is any prevailing wisdom (or existing conventions) for linking language-specific runtime dependencies of a multi-language library.

To be more concrete:

  • I recently ported a small scientific library to use CMake as it’s build system. A build produces a single shared or static library that looks and acts like a normal C library, Large but large chunks of the core-logic are implemented in Fortran. (I imagine that my question isn’t specific Fortran-specific).
  • I want to be able to make it easy for downstream application to consume my project when it’s compiled as a shared or static library. (Supporting the shared library case is fairly easy – this post focuses on the static case)
  • To that end, my project’s Package-Config-file explicitly links the implicit, compiler-specific, Fortran runtime dependencies when a downstream application imports the static-library form of my project with find_package. (The implicit dependencies were inferred while configuring the build).
  • I also want to be able to support consumption of my project, as a static-library, when it is embedded in a downstream build via add_subdirectory or FetchContent. This is trivial when the top-level project lists Fortran as an enabled language. But, challenges arise in the other case (this is the focus of this post).

When the parent doesn’t list Fortran as an enabled language, there seems to be an obvious solution: Recycle the logic used for generating my Package-Config file and explicitly link my project’s implicit Fortran runtime-dependencies. To be robust, I think my project would need to do this whenever it’s built as a static library and it’s not the top level project (regardless of whether the parent project enables Fortran). Are there any issues with doing this?

  • It feels like this solution would be “coloring outside the lines” and I worry that there’s some well-known failure-mode that I’m not thinking about
  • I think this could hypothetically cause issues if the top-level project embeds both my project and some other third party library also involving Fortran into their build. Specifically, issues might arise if the embedded projects used incompatible Fortran toolchains. Should I worry about this? It seems pathological (I can’t imagine this happening unless the other library’s build included some weird, custom logic that tries to influence the default choice of Fortran compiler)
  • Would I be better off simply raising an error and telling the parent project that they need add to their project command (or call enable_language(Fortran))?
  • In case it’s relevant, the project currently enforces a minimum CMake version of 3.16

It seems like this would be a common problem, but I was struggling to find authoritative answers to this problem