Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 335108 - dev-util/cmake picks always the latest boost
Summary: dev-util/cmake picks always the latest boost
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard:
Keywords:
: 398401 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-29 08:06 UTC by Alejandro Dubrovsky
Modified: 2012-01-22 16:28 UTC (History)
4 users (show)

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


Attachments
Changes Modules/FindBoost.cmake to prefer the eselected version of dev-libs/boost. (FindBoost-eselect.patch,1.25 KB, patch)
2012-01-10 20:52 UTC, Duncan Exon Smith
Details | Diff
Fixes Modules/FindBoost.cmake (correct direction). (FindBoost-eselect.patch,1.25 KB, patch)
2012-01-10 20:56 UTC, Duncan Exon Smith
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alejandro Dubrovsky 2010-08-29 08:06:49 UTC
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?
Comment 1 Alejandro Dubrovsky 2010-08-29 08:57:26 UTC
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

Comment 2 Tomáš Chvátal (RETIRED) gentoo-dev 2011-02-21 15:34:15 UTC
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.
Comment 3 Andreas K. Hüttel gentoo-dev 2011-07-31 18:34:22 UTC
We should probably just replace FindBoost.cmake with a Gentoo-specific file. Any volunteers?
Comment 4 Andreas K. Hüttel gentoo-dev 2011-08-27 11:47:06 UTC
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
Comment 5 Johannes Huber gentoo-dev 2012-01-10 16:14:22 UTC
*** Bug 398401 has been marked as a duplicate of this bug. ***
Comment 6 Duncan Exon Smith 2012-01-10 18:16:29 UTC
(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.
Comment 7 Duncan Exon Smith 2012-01-10 20:52:32 UTC
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.
Comment 8 Duncan Exon Smith 2012-01-10 20:56:03 UTC
Created attachment 298549 [details, diff]
Fixes Modules/FindBoost.cmake (correct direction).

Sorry about the previous patch... this one can actually be applied.
Comment 9 Johannes Huber gentoo-dev 2012-01-13 09:06:24 UTC
=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.
Comment 10 Sebastian Luther (few) 2012-01-14 06:59:10 UTC
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.
Comment 11 Tiziano Müller gentoo-dev 2012-01-14 08:25:49 UTC
(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.
Comment 12 Samuli Suominen gentoo-dev 2012-01-15 15:03:54 UTC
(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.
Comment 13 Andreas K. Hüttel gentoo-dev 2012-01-15 16:14:24 UTC
(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?
Comment 14 Tiziano Müller gentoo-dev 2012-01-15 17:07:05 UTC
(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.
Comment 15 Duncan Exon Smith 2012-01-15 23:04:23 UTC
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.
Comment 16 Tiziano Müller gentoo-dev 2012-01-16 07:58:12 UTC
(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.
Comment 17 Duncan Exon Smith 2012-01-16 14:11:56 UTC
(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.
Comment 18 Tiziano Müller gentoo-dev 2012-01-19 06:45:24 UTC
(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.
Comment 19 Duncan Exon Smith 2012-01-19 14:22:03 UTC
(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.
Comment 20 Johannes Huber gentoo-dev 2012-01-22 16:28:56 UTC
As per gentoo-dev mailing list thread and boost maintainer opinion:
Latest boost is wanted.