Adios2: CMake: Enabled Fortran Bindings Infect Downstream C++

[ax3l]

This issue was originally raised in https://github.com/conda-forge/openpmd-api-feedstock/pull/39#issuecomment-554280078 .

Why do I need as a downstream, C++11-only project a Fortran compiler to be able to parse the ADIOS2Config.cmake file when reading it in as a dependency? (Note: ADIOS2 was build with Fortran support but I do not require those bindings downstream.)

This seams unnecessary to me.

-- The Fortran compiler identification is unknown
CMake Error at /home/conda/feedstock_root/build_artifacts/openpmd-api_1573808717385/<...>/lib/cmake/adios2/adios2-config-common.cmake:16 (enable_language):
  No CMAKE_Fortran_COMPILER could be found.

  Tell CMake where to find the compiler by setting either the environment
  variable "FC" or the CMake cache entry CMAKE_Fortran_COMPILER to the full
  path to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
  /home/conda/feedstock_root/build_artifacts/openpmd-api_1573808717385/<...>/lib/cmake/adios2/adios2-config.cmake:29 (include)
  CMakeLists.txt:232 (find_package)


-- Configuring incomplete, errors occurred!

The problem with this is that it commutes to downstream dependencies, even transitively, due to find_dependencies(ADIOS2) in downstream Config.cmake packages...

[ax3l]

@chuckatkins responded:

This is a known issue. The current setup is for all the configured exported targets to be pulled in, which unfortunately means the fortran bindings as well, even if you're not using them. Even with just the C bindings, the two are combined in to one library which can impose excessive usage requirements (theres no way to effectively use the C bindings in C++ 98 code right now, for example). This is actively being addressed though. Part of the library splitting and target re-work that @bradking is working on will be able to eventually resolve this. The idea will be to separate the bindings and serial / mpi distinctions out into distinct components in the imported package so the downstream consumer will only need to pull in the dependencies they need; it's still a work in progress though. For now, all the built targets will be made available to downstream consumers.

:+1:

[bradking]

@chuckatkins this was caused by commit c46e91057a7de6197f40e41b305d5739bf99c333 from #1176. The cmake/adios2-config-common.cmake.in file should not be calling enable_language on behalf of its consumer. At most it should complain if needed languages are not enabled, but typically cmake packages don't do this at all. Do you recall why that was added?

[bradking]

The Fortran bindings are already in a separate adios2_f library so the main adios2 library can still be used without enabling Fortran.

[ax3l]

Just a quick heads-up: is this still broken in master?

[ax3l]

Hi @chuckatkins and @bradking, is there already someone working on a fix for for this? :)

[bradking]

@ax3l I've been working on a long-term series of changes that will eventually split the binding libraries up in a way that will fix this. I'm not working directly toward this issue specifically though.

[ax3l]

@bradking Sounds great, thank you for the heads-up.

[ax3l]

Thanks @bradking and @chuckatkins, will test this with the next release.