MOAB ships custom CMake modules?

[Nico Schlömer]

In ./config/, I find a couple of CMake modules which have allegedly been copied over from /usr/share/cmake-*/Modules/ a while ago (e.g., FindHDF5.cmake). I'm not sure if any changes have been made to those, but sure enough those changes haven't been moved upstream yet. Anyhow, upstream has made improvements to all those packages, and in fact the MOAB FindHDF5.cmake did not find my HDF5 installation, the system one did.

I would hence suggest to remove the custom MOAB Find*.cmake files if they are provided by CMake itself.

[Vijay M]

I made these modifications specifically so that we don't randomly pick up system libraries. This is often a pain in the ass to debug because user might have a custom MPI-dependent HDF5 specified but the system default HDF5 (through either macports or ubuntu) will get picked up without further validation leading to undebuggable linker errors when supporting users. This was the primary reason we have custom Find*.cmake for HDF5 and others.

If you have thoughts on how to support both these scenarios, we are willing to hear.

[Nico Schlömer]

As an example, let's look at FindHDF5 in both MOAB and CMake. On my system (a default Ubuntu 15.04 with HDF5 installed into the default directories), MOAB's logic is not able to find hdf5. CMake's logic is.

On the other hand, on weird HPC installations (and weird is the default as far as I can tell), CMake's logic might fail. For this scenario, CMake provides the variable HDF5_ROOT that anyone can use.

My suggestion would be to use CMake's own logic whenever the corresponding Find*.cmake file allows setting the search path. Also, after find_package(xzy REQUIRED) has completed, we message(STATUS ...) the discovered paths and libraries, and say something like If this is not what you want, try setting HDF5_ROOT. This should give the user and the developer enough debug information while also leveraging the advantages of CMake-maintained Find*.cmake files.

[Vijay M]

Agreed about default behaviors. But as I mentioned, I do not want the configuration system to pick up system installed HDF5 and other dependent libraries since often, these are not compiled with the right MPI wrappers which will lead to bad linkage errors later.

The other important reason we overrode the CMake find_package routines is so that there is uniformity between Autoconf and CMake builds. So all dependencies can now be specified with -DPACKAGE_DIR=INSTALL_DIR (analogous to --with-package=INSTALL_DIR) and -DENABLE_<FEATURE>=ON (analogous to --enable-<feature>).

Supporting two modes of configuration has its merits and issues and this is one way to maintain sanity from a developer's stand-point IMHO.

[Nico Schlömer]

Agreed about default behaviors. But as I mentioned, I do not want the configuration system to pick up system installed HDF5.

I don't understand. The default behavior as i suggested it is to use CMake's own logic first, and if that fails, use MOAB's logic. This means of course that, if a system installation of XYZ is present, CMake's logic will find and pick it. This is them reported to the user with instructions on how to change the default behavior.

[Nico Schlömer]

The other important reason we overrode the CMake find_package routines is so that there is uniformity between Autoconf and CMake builds. So all dependencies can now be specified with -DPACKAGE_DIR=INSTALL_DIR (analogous to --with- package=INSTALL_DIR) and -DENABLE_<FEATURE>=ON (analogous to --enable- <feature>).

We can keep this syntax, I think. The MOAB find_package files would then just wrap CMake's finders, and pass the appropriate MOAB variables (e.g., HDF5_INSTALL_DIR) to CMake ones (HDF5_ROOT).

[Nico Schlömer]

I'll prepare a PR, we can discuss it over there.

[Nico Schlömer]

Resolved by recent PRs.