Adding Boost.MPI variants

[sdebionne]

Boost.MPI is currently disabled in the current package. I'd like to add MPI variants of the boost-cpp package -I am currently maintaining my own builds.

mpi:
  - nompi
  - mpich  # [unix]
  - openmpi  # [unix]

pin_run_as_build:
  mpich: x.x
  openmpi: x.x

Would that work for you?

[isuruf]

Can you submit it as a separate recipe libboost-mpi to staged-recipes?

[sdebionne]

I could but how would that play with the boost-cpp package ? I see that other Boost libraries were packaged as standalone, but they probably overlap (headers) witht main package, no?

In my project, I need all the libraries (not just boost.MPI).

Just to be sure, what are your concerns with having 3 variants -nompi being the default and equivalent to the current package ?

[isuruf]

I see that other Boost libraries were packaged as standalone, but they probably overlap (headers) witht main package, no?

No, the headers are separate, so there's no overlap.

I could but how would that play with the boost-cpp package ?

boost-cpp would be a dependency of libboost-mpi.

Just to be sure, what are your concerns with having 3 variants -nompi being the default and equivalent to the current package ?

boost-cpp is already a big package. We want to divide it up and let's not add any more things to it.

[jakirkham]

Agree with Isuru.

This would also be less burdensome from a feedstock maintenance perspective.

Also seems like the right balance from a user perspective. IOW power users do a little more work, which they should be able to handle; whereas, the average user need not think about these extra features, which may not be relevant to them.

[sdebionne]

OK, that makes sense, thank your for the explanations.

Is this a general move to a boost-cpp package being the main (header only) package while the other (compiled) libraries have their own separate packages?

The libboost (lib) prefix means a dependency to boost-cpp while the other standalone libraries are boost-xyz?

I see a naming conflict already (underscore vs dash):

• https://github.com/conda-forge/boost_mp11-feedstock
• https://github.com/conda-forge/boost-histogram-feedstock

[jakirkham]

Not aware of that no.

With boost-histogram, that is maintained outside the Boost org. So not sure that is an official Boost library (though they may have aspirations to become so one day).

Not sure about the history with boost_mp11. However that is already included in boost-cpp. So maybe we should deprecate that package. Thoughts @conda-forge/boost_mp11?

[sdebionne]

AFAIU, boost-histogram is actually a python binding to the official Boost.Histogram library.

Some Boost libraries are available as standalone libraries (Boost.Hana, Boost.JSON...) that is without dependencies to the main Boost libraries. Maybe Boost.MP11 is one of them... but then these standalone packages are incompatible with the main boost-cpp package:

  run_constrained:
    # Cannot be installed at the same time as boost-cpp as it clobbers the mp11 headers
    - boost-cpp <0a0

[jakirkham]

Yeah that's right. Same story with the boost-histogram conda-forge package

[jakirkham]

Closing as this was resolved with the addition of libboost-mpi in PR ( https://github.com/conda-forge/staged-recipes/pull/18544 )