I have the following dev-libs/boost versions installed: 1.37.0-r1 1.39.0 1.41.0-r3 1.42.0 $ eselect boost list Available boost versions: [1] boost-1.37/default [2] boost-1.39/default * [3] boost-1.41/default [4] boost-1.42/default As shown, 1.39 is selected. Specifying the following on cmake though: FIND_PACKAGE(Boost 1.39 COMPONENTS date_time filesystem iostreams regex serialization signals system thread REQUIRED) finds version 1.42. Clearing the cmake cache and/or running ldconfig don't change this. Reproducible: Always Steps to Reproduce: 1. Install multiple versions of dev-boost 2. eselect an old one 3. Create a CMakeLists.txt with the following: FIND_PACKAGE(Boost 1.39 COMPONENTS date_time filesystem iostreams regex serialization signals system thread REQUIRED) Actual Results: It finds the latest version Expected Results: I'd prefer for it to find the one eselected This is trying to compile a piece of sourcecode not in portage or with any associated .ebuild (opencog: http://bazaar.launchpad.net/%7Eopencog-dev/opencog/trunk/ http://opencog.org/). It doesn't compile with any version later than 1.39 sys-devel/gcc-4.4.4 Running a mostly up-to-date ~x86 setup. Not sure if gentoo can do anything about this. Any cmake person that can give me a workaround?
Quick workaround: Adding EXACT to the FIND_PACKAGE line ie FIND_PACKAGE(Boost 1.39 COMPONENTS date_time filesystem iostreams regex serialization signals system thread REQUIRED EXACT) does the right thing. I suppose there's still maybe a "bug" in the system, but it's definitely a minor one
Cmake FindBoost.cmake need complete overhaul from us to actualy use eselected version first. It is quite important because otherwise the behaviour is kinda tricky.
We should probably just replace FindBoost.cmake with a Gentoo-specific file. Any volunteers?
Before changing anything we need to define the behaviour. My suggestion: 1) Prefer the eselected version if it fulfills the request from the package 2) Otherwise, use the newest possible version present
*** Bug 398401 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Before changing anything we need to define the behaviour. My suggestion: > > 1) Prefer the eselected version if it fulfills the request from the package > 2) Otherwise, use the newest possible version present Along these lines, I just had a look at /usr/share/cmake/MOdules/FindBoost.cmake from dev-util/cmake-2.8.6-r4, and I have a starting point for someone who understands CMake syntax. 1. Figure out the boost version using "eselect boost show". (I don't know how to run that from within CMake.) 2. "eselect boost show" will give a version like "boost-1_46", but we need a list ("1.46.1" "1.46.0" "1.46") or something similar. Figure this out and save it in a variable (let's say) _boost_ESELECTED. 3. Change the setting of _boost_TEST_VERSIONS to have the eselected version show up first, if it's large enough. 3a. In the "else(Boost_FIND_VERSION_EXACT)" block, the _Boost_Known_VERSIONS variable is initialized to versions in descending order. Prepend ${_boost_ESELECTED} to the list of versions that it's initialized to. 3b. Now, the "foreach(version ${_Boost_KNOWN_VERSIONS})" will append the eselected version first to _boost_Test_VERSIONS, if and only if it's actually valid. 4. Now the code that uses _boost_TEST_VERSIONS will check the eselected version before anything else. I would prepare a patch, but this is my first time looking at CMake, and I have no idea how to do #1 or #2.
Created attachment 298547 [details, diff] Changes Modules/FindBoost.cmake to prefer the eselected version of dev-libs/boost. Okay, so I gave it a go. I have not tested this patch, since I have no idea how to run CMake, so someone else should check it over.
Created attachment 298549 [details, diff] Fixes Modules/FindBoost.cmake (correct direction). Sorry about the previous patch... this one can actually be applied.
=dev-util/cmake-2.8.6-r5 in kde overlay available. It contains a new FindBoost.cmake patch, which hopefully solves the problem. @Duncan thank you for your work, but unfortunately your patch doesnt work.
Why is it a bad thing that it picks latest boost? There are ebuilds explicitly patched to always use latest boost. Imo the point of eselect boost is that if you're developing applications using boost, you can easily switch between different boost versions for testing. But ebuilds should always use latest.
(In reply to comment #9) > =dev-util/cmake-2.8.6-r5 in kde overlay available. It contains a new > FindBoost.cmake patch, which hopefully solves the problem. > > @Duncan thank you for your work, but unfortunately your patch doesnt work. This is definetely wrong. If the dependency is: "|| ( dev-libs/boost:1.47 dev-libs/boost:1.48 )" a package manager assumes the "best matching" version is used by the package. That means: the latest version available for the selected arch and keyword. If you are starting to use whatever has been selected by the user you make it impossible for a package manager to correctly calculate reverse dependencies. The boost-eselect managed symlinks were designed with two objectives in mind: * make transition from unslotted boost to slotted boost easier for Gentoo devs * since boost upstream has no standard concerning slotted installation, make it easier for developers who write software on Gentoo using boost to select boost versions they want to use for their development without having to care about Gentoo-specific slotting of boost. Gentoo packages must always use the latest boost version available.
(In reply to comment #10) > Why is it a bad thing that it picks latest boost? I have no idea. Using anything other than latest from within ebuilds would be in fact a bug in my opinion. I suppose this is a INVALID/WONTFIX.
(In reply to comment #12) > (In reply to comment #10) > > Why is it a bad thing that it picks latest boost? > > I have no idea. Using anything other than latest from within ebuilds would be > in fact a bug in my opinion. I suppose this is a INVALID/WONTFIX. Well, let's ask the question the other way round, since the boost team provides eselect boost: Why do we allow someone to eselect a version of boost, if this is then not respected at all?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #10) > > > Why is it a bad thing that it picks latest boost? > > > > I have no idea. Using anything other than latest from within ebuilds would be > > in fact a bug in my opinion. I suppose this is a INVALID/WONTFIX. > > Well, let's ask the question the other way round, since the boost team provides > eselect boost: > > Why do we allow someone to eselect a version of boost, if this is then not > respected at all? Please read my answer above.
I disagree with Sebastian and Tiziano. eselect-boost is unnecessary for development... it's trivial to add CFLAGS+=-I/usr/include/boost-1_48 LDFLAGS+=-L/usr/lib64/boost-1_48 to makefiles (and cmake apparently has a trivial way to select an exact version of boost). I see no use case for eselect-boost here. (Well, it doesn't hurt, but...) However, I see a strong use case for eselect-boost choosing the "system" boost used by packages. For example, it is impossible to have your system use a stable version of boost, but develop against (let's say) a newer hard-masked version like 1.48. Upgrading any package that uses boost would require uninstalling boost-1.48.0, upgrading the package, and then reinstalling boost-1.48.0. Isn't this how other eselects modules work, like python, emacs, ctags, etc? I have older (and newer) versions of python installed for development, but I have the latest stable 2.x and 3.x versions selected for the system python. Similarly, I have gcc-4.6.2 installed for development, but my system GCC is the most recent version stable on amd64 (4.5.x I think). Certainly, if a package *requires* boost-1.47.0 or later and boost-1.46.0 is eselected, it should use the 1.48.0 package. But in my opinion, the eselected version should be preferred, as is the case with other eselect modules that I'm familiar with.
(In reply to comment #15) > I disagree with Sebastian and Tiziano. eselect-boost is unnecessary for > development... it's trivial to add > CFLAGS+=-I/usr/include/boost-1_48 > LDFLAGS+=-L/usr/lib64/boost-1_48 > to makefiles (and cmake apparently has a trivial way to select an exact version > of boost). I see no use case for eselect-boost here. (Well, it doesn't hurt, > but...) Ok, and since the transition period from unslotted boost to slotted boost I'll last rite eselect-boost. > However, I see a strong use case for eselect-boost choosing the "system" boost > used by packages. For example, it is impossible to have your system use a > stable version of boost, but develop against (let's say) a newer hard-masked > version like 1.48. Upgrading any package that uses boost would require > uninstalling boost-1.48.0, upgrading the package, and then reinstalling > boost-1.48.0. > > Isn't this how other eselects modules work, like python, emacs, ctags, etc? I > have older (and newer) versions of python installed for development, but I have > the latest stable 2.x and 3.x versions selected for the system python. > Similarly, I have gcc-4.6.2 installed for development, but my system GCC is the > most recent version stable on amd64 (4.5.x I think). > > Certainly, if a package *requires* boost-1.47.0 or later and boost-1.46.0 is > eselected, it should use the 1.48.0 package. But in my opinion, the eselected > version should be preferred, as is the case with other eselect modules that I'm > familiar with. No, packages are built against python/ruby/whatsoever versions specified via the corresponding USE flags, not what has been selected via eselect, so those are counterexamples. The only example I know is gcc. But since gcc is in the system package and no package usually directly depends on it, it is still not the same case as boost.
(In reply to comment #16) > > Isn't this how other eselects modules work, like python, emacs, ctags, etc? I > > have older (and newer) versions of python installed for development, but I have > > the latest stable 2.x and 3.x versions selected for the system python. > > Similarly, I have gcc-4.6.2 installed for development, but my system GCC is the > > most recent version stable on amd64 (4.5.x I think). > > No, packages are built against python/ruby/whatsoever versions specified via > the corresponding USE flags, not what has been selected via eselect, so those > are counterexamples. > The only example I know is gcc. But since gcc is in the system package and no > package usually directly depends on it, it is still not the same case as boost. Hold on... are you saying that if I have dev-lang/python:3.1 and dev-lang/python:3.2 both installed, and I run: eselect python set --python3 python3.1 then packages will build against python3.2? That's contrary to my experience.
(In reply to comment #17) > (In reply to comment #16) > > > Isn't this how other eselects modules work, like python, emacs, ctags, etc? I > > > have older (and newer) versions of python installed for development, but I have > > > the latest stable 2.x and 3.x versions selected for the system python. > > > Similarly, I have gcc-4.6.2 installed for development, but my system GCC is the > > > most recent version stable on amd64 (4.5.x I think). > > > > No, packages are built against python/ruby/whatsoever versions specified via > > the corresponding USE flags, not what has been selected via eselect, so those > > are counterexamples. > > The only example I know is gcc. But since gcc is in the system package and no > > package usually directly depends on it, it is still not the same case as boost. > > Hold on... are you saying that if I have dev-lang/python:3.1 and > dev-lang/python:3.2 both installed, and I run: > eselect python set --python3 python3.1 > then packages will build against python3.2? That's contrary to my experience. The point is: as soon as you have python-3 installed, packages will build for it. For ruby you can control via USE flags for which versions to build (which is a much cleaner way and I hope we can move python to that). But those are language interpreters. If you want to compare boost to something, take sys-libs/db.
(In reply to comment #18) > The point is: as soon as you have python-3 installed, packages will build for > it. For ruby you can control via USE flags for which versions to build (which > is a much cleaner way and I hope we can move python to that). > > But those are language interpreters. If you want to compare boost to something, > take sys-libs/db. I'm not an expert, so I'll back off and defer to you. A few final points: - Managing which Boost version to build against with USE flags would be great, but that's also not an option. - There are lots of eselect modules that go the way I think Boost's should work. The ones I know about are: languages, which you've pointed out are different beasts; emacs, which I guess *is* a language; blas and cblas, which choose packages rather than versions of a single package; kernel, which does choose library versions to link against, but is a special case of a different sort. - You've made it clear that this was not the intended purpose of eselect-boost, so I realize now that this should be a feature request rather than a bug report.
As per gentoo-dev mailing list thread and boost maintainer opinion: Latest boost is wanted.
