The boost is part headers part compiled libraries. The boost build system is setup such that users can select which libraries they want to build if all the compiled libraries are no desired. There is no way to do this with the current ebuild. Being able to select which libs get compiled would be beneficial to gentoo users. For example, some of the kde ebuilds depend on boost but the only need shared_prt header and the programs_options lib. On uclibc system all boost libs dont build, but the ones needed by kde do build. Because the current boost ebuild forces all libs to be compiled boost breaks and kde cant be installed on a uclibc system. Reproducible: Always Steps to Reproduce: 1. unpack 2008 uclibc stage3 2. emerge boost Actual Results: boost fails to compile
There are a number of ways this could be fixed but I don't know which one is most preferred by gentoo devs... 1. Add USE_EXPAND="BOOST_LIBS" to the base profile and then add IUSE_BOOST_LIBS to the boost ebuild with use flags for each lib... (this is what I think is best) 2. Same as 1. but no USE_EXPAND (i have a working ebuild like this that I can post here) 3. Implement something like USE="savedconfig" (idk how this would be done but im sure its possible) Input from others about this would be nice!!
Created attachment 183286 [details, diff] Add use flags for each compiled boost lib This patch sets the stage for USE_EXPAND="BOOST_LIBS" in the boost-1.35.0-r2 ebuild...
You might be interested to see discussion on that in bug #234902 specificly comment #50. I like your approach though -- one ebuild that installs "parts" other EAPI 2 enabled packages can depend on. I have one note about taste: you may wish to keep IUSE_BOOST_LIBS sorted -- it's easier to maintain.
Also, keep in mind that you need to provide some way to enable all libs, that being both for users that don't want to specify 20 flags in their configs and watch for new ones if they appear with updates. Plus, you might be interested in seeing output of "equery depends -a dev-libs/boost" (or similar with adjutrix if you're a paludis user) that would give you a rough idea of how many packages would need to have dependencies updated to make sure all required components are pulled in.
(In reply to comment #4) > Also, keep in mind that you need to provide some way to enable all libs, that > being both for users that don't want to specify 20 flags in their configs and > watch for new ones if they appear with updates. > > Plus, you might be interested in seeing output of "equery depends -a > dev-libs/boost" (or similar with adjutrix if you're a paludis user) that would > give you a rough idea of how many packages would need to have dependencies > updated to make sure all required components are pulled in. > well with EAPI=2 couldnt all the boost libs be prefixed with + to make them default enabled, then uses would only have to worry about disabling libs
you forgot that we'd have to track the dependencies between the libs as well? (if any) as well as packages have to depend on boost then as dev-libs/boost[boost_lib_X1,boost_lib_X2]
(In reply to comment #6) > you forgot that we'd have to track the dependencies between the libs as well? > (if any) as well as packages have to depend on boost then as > dev-libs/boost[boost_lib_X1,boost_lib_X2] > what do you mean the dependencies between the libs, are you saying boost_lib_X1 might depend on boost_lib_X1??
Yes. I didn't check for it, but it's possible.
Created attachment 183653 [details, diff] Add IUSE_BOOST_LIBS This is an update of my other patch, it adds the boost_libs_ prefix to the IUSE_BOOST_LIBS, it puts the boost_lib in alphabetical order like suggested, and it simplifies the --without-<lib> section
(In reply to comment #8) > Yes. I didn't check for it, but it's possible. > According to a boost dev, "if --witout=Y causes library X to fail to build because it depends on Y, this is a bug in library X ...... If library X spells out dependency on Y, as it should, then Y will be built no matter what." So it looks like we shouldnt have to worry about deps ;)
(In reply to comment #10) > So it looks like we shouldnt have to worry about deps ;) I must disagree. If you're providing an option to turn something off, turn it off or bark at user for making incompatible choice. Too bad no gentoo EAPI allows to specify it dep resolution time.
(In reply to comment #11) > (In reply to comment #10) > > So it looks like we shouldnt have to worry about deps ;) > > I must disagree. If you're providing an option to turn something off, turn it > off or bark at user for making incompatible choice. Too bad no gentoo EAPI > allows to specify it dep resolution time. > (In reply to comment #11) > (In reply to comment #10) > > So it looks like we shouldnt have to worry about deps ;) > > I must disagree. If you're providing an option to turn something off, turn it > off or bark at user for making incompatible choice. Too bad no gentoo EAPI > allows to specify it dep resolution time. > (In reply to comment #11) > (In reply to comment #10) > > So it looks like we shouldnt have to worry about deps ;) > > I must disagree. If you're providing an option to turn something off, turn it > off or bark at user for making incompatible choice. Too bad no gentoo EAPI > allows to specify it dep resolution time. > (In reply to comment #11) > (In reply to comment #10) > > So it looks like we shouldnt have to worry about deps ;) > > I must disagree. If you're providing an option to turn something off, turn it > off or bark at user for making incompatible choice. Too bad no gentoo EAPI > allows to specify it dep resolution time. > Well i suppose once the source is unpacked there would be a way to figured out what links to what and if something is disabled that need to link to something enabled we could bail out and warn about it. It either that or ever release go though each permutation of libs on/off and hardcode the deps.
Alright whipped up a little script that determines if a dependency is unmet. I tested this on 1.38.0 since 1.35.0 does not have any interlib deps... Of course the only way of doing this is after the source is unpacked but this is the best I can come up with atm... This script was just a proof of concept, I can put this into an ebuild to test but I figured I would show it on here before I did that... #!/bin/bash available_libs="date_time filesystem function_types graph iostreams math mpi program_options python regex serialization signals system test thread wave" wanted_libs="program_options python filesystem" for lib in $wanted_libs; do deps=$(cat libs/$lib/module.cmake | grep DEPENDS | sed "s:^boost_module($lib DEPENDS ::;s:)$::") for dep in $deps; do if [[ -n $(echo $available_libs | grep $dep) ]]; then if [[ -n $(echo $wanted_libs | grep -c $dep) ]]; then echo "Boost Lib \"$dep\" is required" fi fi done done
(In reply to comment #13) > Alright whipped up a little script that determines if a dependency is unmet. I > tested this on 1.38.0 since 1.35.0 does not have any interlib deps... Of course > the only way of doing this is after the source is unpacked but this is the best > I can come up with atm... This script was just a proof of concept, I can put > this into an ebuild to test but I figured I would show it on here before I did > that... > > #!/bin/bash > > available_libs="date_time filesystem function_types graph iostreams math mpi > program_options python regex serialization signals system test thread wave" > wanted_libs="program_options python filesystem" > > for lib in $wanted_libs; do > deps=$(cat libs/$lib/module.cmake | grep DEPENDS | sed > "s:^boost_module($lib DEPENDS ::;s:)$::") > for dep in $deps; do > if [[ -n $(echo $available_libs | grep $dep) ]]; then > if [[ -n $(echo $wanted_libs | grep -c $dep) ]]; then > echo "Boost Lib \"$dep\" is required" > fi > fi > done > done > I've been on vacation to I have not followed up on this till now... are people ok with something like this to check dependencies before compiling begins or are you all waiting for me to put it in a ebuild before you comment?
*** Bug 310207 has been marked as a duplicate of this bug. ***
*** Bug 410621 has been marked as a duplicate of this bug. ***
JFYI, I started on a script[0] for a boost ebuild maintainer. 1. to see what source libraries are available and 2. its interdependencies printed ready to use for example with REQUIRED_USE (minor manual adjustment necessary) copy the script[0] into the extracted boost directory, make it executable and have fun! [0] https://github.com/geki-yaba/gekis-playground/blob/master/scripts/boost_libdeps
Hello, I was thinking about it some days ago, as building all boost libs because I need only some of them is a waste of time IMHO. So I came up with another solution, I don't know if it is better or worse, but it would solve the dependencies issue easily : why not doing something like qt and make a package per lib? I know that qt already ships splitted archives, and as I have never studied boost build system I don't know if this would be this simple. I would see something like `dev-libs/boost-multimap` for a specific lib, and keeping `dev-libs/boost` as a meta package to get all of them in a row and avoid breaking existing packages dependencies, which would allow a smooth transition. Is it an idea as good as it seems or did I miss something?
(In reply to legrand.cedric.01 from comment #18) > I was thinking about it some days ago, as building all boost libs because I > need only some of them is a waste of time IMHO. I did this back in the days. I was recommended not to do so. read changes back to the beginning at [0]. So, I switched to a single package with use flags enabling its libraries. Nowadays[1], I use USE_EXPAND to have it properly: $ grep BOOST_LIBS /etc/portage/package.use dev-libs/boost threads BOOST_LIBS: date_time filesystem program_options python regex signals thread [0] https://code.google.com/p/gekis-playground/source/list [1] https://github.com/geki-yaba/gekis-playground
This is a massive maintenance burden, for real little gain. Are you willing to fix all revdeps to make the transition workable?
No proposed solution.