Use CMake build for Linux as well

[sdebionne]

If CMake is used for dowstream projects, find_package(HDF5) is inconsistant across platform.

1. On Windows, since CMake is used to build the package, a CMake package config file is generated and find_package(HDF5) uses the hdf5-config.cmake that exports an HDF5 target. Using HDF5 is simple:

target_link_libraries(my_program
    hdf5::hdf5-static
)

2. On Linux, since autoconf is used, find_package(HDF5) works the old way and uses FindHDF5.cmake which does not export a target. Using HDF5 requires a more verbose CMake code:

target_include_directories(my_program
    ${HDF5_INCLUDE_DIRS}
)

target_compile_definitions(my_program
    ${HDF5_DEFINITIONS}
)

target_link_libraries(my_program
    ${HDF5_LIBRARIES}
)

Is there any reasons not to use CMake for both platforms in the first place?

Environment (conda list):

``` $ conda list hdf5 1.10.4 hb1b8bf9_0 ```

Details about conda and system ( conda info ):

$ conda info
          conda version : 4.6.2
    conda-build version : not installed
         python version : 3.7.1.final.0
               platform : linux-64
             user-agent : conda/4.6.2 requests/2.21.0 CPython/3.7.1 Linux/4.4.0-17763-Microsoft debian/9 glibc/2.24
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

[marcelotrevisani]

I think that is not an issue, in your case you can give some hints to cmake to find the hdf5
such as

find_package(HDF5 PATHS folder_hdf5)

or you can use PATH_SUFFIXES as well
https://cmake.org/cmake/help/v3.0/command/find_package.html

cmake does not work well with virtual environment, I think they are trying to improve it.

[sdebionne]

I have no problem with finding the packages. The issue is more that they are built in different ways on Windows and Linux.

cmake does not work well with virtual environment, I think they are trying to improve it.

I have never had any issue with CMake and virtual environment. As long as one use

-DCMAKE_FIND_ROOT_PATH=$CONDA_PREFIX
-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY

when invoking CMake from the recipe that truly chroot CMake to the env.

[marcelotrevisani]

I faced some problems with cmake to use in a virtual environment in the past, there is still an issue opened in kitware regarding that and also they improved in the recent versions to find libraries and other stuff in virtual environments.

One person who may give you more explanation about it, is @mingwandroid

[mingwandroid]

I have never had any issue with CMake and virtual environment. As long as one use

-DCMAKE_FIND_ROOT_PATH=$CONDA_PREFIX
-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY

I do not think this works for finding packages in the sysroot. CMake needs to actually be taught how to figure out sysroots for itself to be honest.

It really is a very friendly build system. It will look all over your filesystem in countless folders to find things you might want to include or link to. Really very friendly indeed.

[sdebionne]

I don't know if CMake is to friendly or not, but I agree that there is a lot of variables that influence the search paths!

According to the doc of CMAKE_FIND_ROOT_PATH_MODE_XXX, if set to ONLY, then only the roots in CMAKE_FIND_ROOT_PATH will be searched. In my experience, system libraries are indeed not searched / found if this is set to ONLY.

For sysroot, you have CMAKE_SYSROOT, but is it really necessary to set it?

CMAKE_FIND_NO_INSTALL_PREFIX is another variable that can be used, but in the case of conda packages, it should not be necessary.

@marcelotrevisani Could you give me a link to the issue reported in Kitware bug tracker, please?

[tadeu]

Also FindHDF5 is too generic and have no information about how HDF5 was built. If HDF5 were built with CMake, the HDF5 package would install files like HDF5-config.cmake that would have a more complete configuration.

[tadeu]

I think this problem would not happen if HDF5 were being built with CMake: conda-forge/libitk-feedstock#7

[sdebionne]

@tadeu Thanks for adding grist to the mill!

@marcelotrevisani I'm willing to contribute a PR, would you be OK with that?

[marcelotrevisani]

@tadeu Thanks for adding grist to the mill!

@marcelotrevisani I'm willing to contribute a PR, would you be OK with that?

Sorry for my delay
You can open a PR, we will review and discuss that to see if it would be better
But feel free to contribute ! :)

[marcelotrevisani]

Some issues which I found in the past regarding virtual environments in cmake are:
https://gitlab.kitware.com/cmake/cmake/issues/18302
https://gitlab.kitware.com/cmake/cmake/issues/18408

there are still more and more if you search about it

[sdebionne]

I see. It is not clear to me though if these issues are real when running conda build in a clean docker environment.

[tadeu]

Also those issues are for venv, I don't know how much they apply to conda

[nicoddemus]

I'm willing to contribute a PR, would you be OK with that?

@sdebionne did you have any success on this front?

I'm being bitten by this as well: I'm building my lib with CMake on Windows successfully, but I don't the corresponding FindHDF5.cmake configuration on Linux.

[marcelotrevisani]

Also those issues are for venv, I don't know how much they apply to conda

Actually, the problems are also related to sysroot (not those which I pointed out)
cmake is not that good when dealing with it. But I do not oppose building hdf5 with cmake. However, we may just add the cmake files for hdf5 with the package, or maybe add an issue on Kitware to also export the targets

[ndevenish]

FWIW as of CMake 3.19 the FindHDF5 module does finally export targets: https://cmake.org/cmake/help/v3.19/module/FindHDF5.html. However, from the example in the inital hdf5::hdf5-static doesn't seem to be explicitly separate, so maybe not a complete solution.