ADIOS2 Support

[ax3l]

Release 0.10.0-alpha adds support for ADIOS2.

Follow-up to #37

Checklist

• [x] Used a fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ax3l]

@conda-forge-admin, please rerender

[ax3l]

cc @chuckatkins @williamfgc: I saw this before with ADIOS2 and am wondering: 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.)

Does this look like an issue? 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!

[williamfgc]

@ax3l thanks for bringing this up, is your setup using ninja? I've seen this issue before with it since ninja doesn't have official support for Fortran. Still, libadios2_f.so (F90) builds on top of libadios2.so (C++), so my initial guess is the same as yours, but it might be wrong. @chuckatkins would be able to provide more context. Please feel free to open an issue upstream.

[chuckatkins]

cc @chuckatkins @williamfgc: I saw this before with ADIOS2 and am wondering: 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 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.

[ax3l]

Thanks for the details, sounds good to me.

No, I am not using ninja.

I will report this then upstream again so we have an issue number to keep track of. The problem with this is that it commutes to downstream dependencies, even transitively, due to find_dependencies(ADIOS2) in downstream Config.cmake packages...

[ax3l]

Ok, so I applied a work-around for now but this will only push the problem further downstream to the next CMake consumer...

[ax3l]

@conda-forge-admin, please rerender