Missing components showing up in dependent packages

[h-vetinari]

In the boost unification (#164), we tried as much as possible - aside from the output reshuffling - to keep the build exactly as before. In particular, the build script is taken essentially verbatim from the previous boost-cpp (with the exception of adding the python build to have all the headers at once).

However, during the migration I'm now seeing cases of missing components, e.g. here

-- Could NOT find Boost (missing: system serialization iostreams) (found suitable version "1.82.0", minimum required is "1.58.0")

or here

Could NOT find Boost (missing: thread system date_time chrono) (found suitable version "1.82.0", minimum required is "1.55.0")

These all sound very stdlib-related, so perhaps those feedstocks are defaulting to a too-old C++ version?

[isuruf]

libboost-python-devel probably needs libboost-devel as a run time requirement. (And also a run_exports)

[h-vetinari]

Ah yeah, that makes sense. PR coming up.

Next issue: folly cannot find a header anymore,

In file included from /tmp/tmpp7qryo05/info/recipe/arena_test.c:1:
/home/conda/feedstock_root/build_artifacts/folly_1696034969559/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_/include/folly/memory/Arena.h:25:10: fatal error: boost/intrusive/slist.hpp: No such file or directory
   25 | #include <boost/intrusive/slist.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

even though it's clearly still part of boost.

[h-vetinari]

(And also a run_exports)

I'm not sure that's the best pattern here? What can happen is that a library really only depends on libboost-python at runtime, but expressing that accurately now requires:

build:
  ignore_run_exports:
    - libboost

I think it would be better to remove the libboost run-export from libboost-python-devel, and let recipes that require libboost at runtime also host-depend on libboost-devel? That way we'd remove the footprint of a couple of packages, reduce the complexity of using the libraries (no ignore_run_exports necessary), and make dependencies more explicit.

Thoughts?

PS. Motivated by an example I saw in the boost migration after using the new builds from #177.

[isuruf]

Sure we can remove run_exports, but to make sure things work fine, we should enable error_overlinking in conda-forge.yml in the migrator.

[h-vetinari]

I've been manually verifying the link check on every boost PR so far, and error_overlinking would make the migration several times more complicated, because so many feedstocks have spurious run-deps that they haven't cleaned up. Of course I see the value in enabling that, but let's please not couple this with the boost rename/reshuffle migration.

What do you think about doing it either in the next boost migration, or with a separate conda-forge wide migration to enable this everywhere?

[h-vetinari]

This has been handled by adding a dependence (& run-export) from libboost-python-devel to libboost for the 1.82 migration, which we undid (in https://github.com/conda-forge/boost-feedstock/pull/189) for 1.84. There'll be a small number of feedstocks that will need fixing, and I'll keep an eye on them. In the meantime, this issue can be closed.