Problem with exported pomerol::pomerol target on MacOS about pomerol HOT 7 CLOSED

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.

from pomerol.

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.

from pomerol.

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

from pomerol.

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.
exercism/cpp#217

from pomerol.

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?)

from pomerol.

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.

from pomerol.

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

from pomerol.