Split boost into multiple outputs

[edolstra]

Issue description

Currently all Boost libraries are installed into the same output (out). This means that a package that uses any library gets all of them in its closure, plus assorted crap like icu4c (31 MiB). Also, it includes static libraries.

So we should move at least some of them to separate outputs. E.g. Nix only uses libboost_context so it would be nice if there was a boost.context output.

[vcunat]

IIRC it's even possible to build them separately.

[goertzenator]

libboost_context is currently being copied into the nix output which creates a collision if boost is also in the current environment.

My use case is building a mixture of nix and non-nix things that require both nix and boost. I can think of a number of work-arounds, but I just wanted to point out this issue.

building '/nix/store/k2x7sv95g2a6kknvi45faq8fmasllbyc-env.drv'...
collision between `/nix/store/0jwj95ckhizk9mx087y21kkdz2n1wfbj-boost-1.67_0-i586-unknown-linux-gnu/lib/libboost_context.so' and `/nix/store/9pwfxk37fsjpmbnbam0h866fzwnsvfpj-nix-2.1.3/lib/libboost_context.so'
builder for '/nix/store/k2x7sv95g2a6kknvi45faq8fmasllbyc-env.drv' failed with exit code 25
error: build of '/nix/store/k2x7sv95g2a6kknvi45faq8fmasllbyc-env.drv' failed

[timokau]

The issue @goertzenator reported also leads to problems with a user nix installation using home-manager with some package that depends on boost.

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[stale]

I marked this as stale due to inactivity. → More info

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/boost-python-questions/13767/6

[stale]

I marked this as stale due to inactivity. → More info

[mikepurvis]

It would be great to see this tackled at some point. Given this:

IIRC it's even possible to build them separately.

I wonder if it might even be better to adopt a structure similar to what's been done with cudaPackages, so have like boostPackages.boost_chrono, boostPackages.boost_coroutine, and so on. This would also provide a natural structure for versioning the boost scope as a singular unit— just set boostPackages = boost177Packages, same as Python, and you're away to the races.

[RaitoBezarius]

If I have time, I would try to bring this change for 23.11.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-11-27-nix-team-meeting-minutes-107/36112/1

[roberth]

So these outputs would all operate in the way dev outputs normally do?
Not sure about using multi-outputs this way, although I suppose it saves a few instantiations.
As for the library binaries (static or shared libraries and such), I don't see how that could work in such a very-many-outputs derivation as consumed by stdenv, unless we're allowed to mix and match arbitrary outputs into package attrsets whose outputs are not just a mirror of the derivation outputs. (ie some of the flexibility discussed in NixOS/nix#6507)

[Ericson2314]

@roberth I hope as @vcunat wrote long ago, we can just build them separately, and that solves these issues.

[roberth]

Yeah I was trying to clarify the constraints we have on the Nix semantics side of things.
Doesn't look that hard: https://stackoverflow.com/questions/4714289/boost-libraries-build-only-what-i-need
So it seems that the other open question is how to structure these new packages in Nixpkgs. Like how does it interact with the multiple boost versions that are supported? Where do the new attributes go, what's the naming scheme? New package sets?
I don't think we have particularly hard requirements on these things, so someone could just give it a go.