Problem with exported pomerol::pomerol target on MacOS

[krivenko]

This issue was discovered by Sasha Lichtenstein while he was trying to build pomerol2triqs on his MacBook Pro using Boost 1.72.

CMake was issuing the following error message,

 CMake Error at c++/CMakeLists.txt:1 (add_library):
  Target "pomerol2triqs_c" links to target "Boost::mpi" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

The problem roots in the way pomerol::pomerol CMake target is exported. The installed share/pomerol/pomerol.cmake contains the following lines:

set_target_properties(pomerol::pomerol PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "/usr/include/eigen3;/usr/include;/usr/include;${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "/usr/lib64/libmpi_cxx.so;/usr/lib64/libmpi.so;Boost::mpi;Boost::serialization"
)

On my own Linux laptop those lines are rather different and include explicit paths to the compiled Boost components.

set_target_properties(pomerol::pomerol PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "/usr/include/eigen3;/usr/include;/usr/include;${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "/usr/lib64/libmpi_cxx.so;/usr/lib64/libmpi.so;/usr/lib64/libboost_mpi-mt.so;/usr/lib64/libboost_serialization-mt.so"
)

I wonder if it's a duty of the consumer's CMake code to always import the Boost targets by calling find_package(Boost) along with find_package(pomerol).

[aeantipov]

I remember this issue appearing in the context of ALPSCore. The idea of sharing dependencies is to enforce the correct linking (like, say when multiple modules on clusters are present). It should 'always work' in a sense that as long as (1) pomerol is compiled correctly and tests pass (2) the export is correct, the dependent library should just get it. However in this case it seems that INTERFACE_LINK_LIBRARIES are wrong.

[aeantipov]

In particular, I remember now, without this one ends up often linked to a system boost. In a sense one has to run cmake with the arguments like BOOST_ROOT the same as those used for compilation. So the goal of providing libraries is to avoid that.

[krivenko]

Looks like our own code has little to do with this issue. On macOS, find_package(Boost) sets Boost_INCLUDE_DIRS and Boost_LIBRARIES to the following values respectively,

-- Boost includes: /usr/local/include
-- Boost libs: Boost::mpi;Boost::serialization

https://travis-ci.org/github/aeantipov/pomerol/jobs/666864157#L740

[aeantipov]

There's a thread for some package having a similar issue. We should restrict the maximum version of boost because cmake bindings are always lagging behind. https://github.com/exercism/cpp/issues/217

[krivenko]

My impression is that it's totally legal for FindBoost.cmake to put Boost target names into Boost_LIBRARIES. I just don't understand why its behavior is inconsistent between platforms (CMake versions? Boost versions?)

[krivenko]

Pomerol 2.0 does not depend on Boost.MPI and Boost.Serialization anymore. One should try to build the updated pomerol2triqs on macOS and see if this issue is actually gone.

[krivenko]

I am closing this issue since pomerol2triqs is sucessfully built by a macOS 11 GitHub Actions runner now.

https://github.com/pomerol-ed/pomerol2triqs/actions/runs/3619457035/jobs/6100523644