Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 260404 - dev-libs/boost provides no way to select which libs get built - solution needed
Summary: dev-libs/boost provides no way to select which libs get built - solution needed
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: David Seifert
URL:
Whiteboard:
Keywords:
: 310207 410621 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-26 17:05 UTC by Ryan Hope
Modified: 2019-08-28 14:59 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add use flags for each compiled boost lib (iuse-boost-libs.patch,1.63 KB, patch)
2009-02-26 17:24 UTC, Ryan Hope
Details | Diff
Add IUSE_BOOST_LIBS (iuse-boost-libs.patch,1.31 KB, patch)
2009-03-02 09:16 UTC, Ryan Hope
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hope 2009-02-26 17:05:44 UTC
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
Comment 1 Ryan Hope 2009-02-26 17:09:49 UTC
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!!
Comment 2 Ryan Hope 2009-02-26 17:24:38 UTC
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...
Comment 3 Łukasz Michalik 2009-02-27 15:16:40 UTC
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.
Comment 4 Łukasz Michalik 2009-03-01 23:24:26 UTC
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.
Comment 5 Ryan Hope 2009-03-02 05:22:06 UTC
(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
Comment 6 Tiziano Müller (RETIRED) gentoo-dev 2009-03-02 05:42:45 UTC
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]
Comment 7 Ryan Hope 2009-03-02 07:10:51 UTC
(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??
Comment 8 Tiziano Müller (RETIRED) gentoo-dev 2009-03-02 08:30:50 UTC
Yes. I didn't check for it, but it's possible.
Comment 9 Ryan Hope 2009-03-02 09:16:39 UTC
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
Comment 10 Ryan Hope 2009-03-02 09:18:41 UTC
(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 ;)
Comment 11 Łukasz Michalik 2009-03-02 09:43:24 UTC
(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.
Comment 12 Ryan Hope 2009-03-02 16:20:55 UTC
(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.
Comment 13 Ryan Hope 2009-03-02 18:50:55 UTC
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
Comment 14 Ryan Hope 2009-03-16 22:58:27 UTC
(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?
Comment 15 Tiziano Müller (RETIRED) gentoo-dev 2012-08-20 19:29:11 UTC
*** Bug 310207 has been marked as a duplicate of this bug. ***
Comment 16 Tiziano Müller (RETIRED) gentoo-dev 2012-08-20 19:43:31 UTC
*** Bug 410621 has been marked as a duplicate of this bug. ***
Comment 17 Hanno Zysik (geki) 2015-07-18 20:11:51 UTC
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
Comment 18 legrand.cedric.01 2015-08-01 09:12:07 UTC
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?
Comment 19 Hanno Zysik (geki) 2015-08-01 10:21:12 UTC
(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
Comment 20 David Seifert gentoo-dev 2019-04-19 10:15:38 UTC
This is a massive maintenance burden, for real little gain. Are you willing to fix all revdeps to make the transition workable?
Comment 21 David Seifert gentoo-dev 2019-08-28 14:59:22 UTC
No proposed solution.