Making FindBoost prefer Boost_ROOT

Alexander Neundorf neundorf at kde.org
Wed Mar 26 23:19:57 GMT 2008


On Thursday 27 March 2008, Matthew Woehlke wrote:
> Alexander Neundorf wrote:
> > On Wednesday 26 March 2008, Matthew Woehlke wrote:
> >> In order to get my Boost_ROOT honored rather than the system boost in
> >> /usr/include (which is too old), I had to make the following changes to
> >> FindBoost.cmake (this is from kdevplatform, but I've had to copy the
> >> module to pimlibs and now kdesdk also, due to the module from cmake
> >> 2.4.6 being similarly inadequate). Should I commit this?
> >
> > With cmake 2.6 you can set the env. variable CMAKE_PREFIX_PATH, e.g.
> > to /my/boost/install/dir, and then cmake will search this first (and
> > append include/, lib/ and bin/ accordingly).
> > Would that help in your case ?
>
> er... no, not really. CMake 2.6 isn't out yet, 

Yes, but it will be in a few days.

> nor is it (currently) required by trunk. 

This will stay this way as long as possible.
But I think if there is a feature in 2.6 which helps you and which doesn't 
require any changes in the cmake files then it's ok if you use this feature.

> Besides I'd rather not pollute CMAKE_PREFIX_PATH with
> random packages' stuff when I can use Boost_ROOT instead. (Shouldn't
> that be upper-case?)

I don't think introducing an environment variable for every package is a good 
idea.
Do you have boost installed to a separate location or to your own custom 
install directory, like e.g. $HOME/install/ ?
This would be the exact purpose for CMAKE_PREFIX_PATH.

> I've actually had a modified version of FindBoost for quite some time,
> and just haven't complained about it. I do so now because kdesdk started
> breaking, and I accidentally clobbered the version I had previously hacked.
>
> Given the number of boost users in KDE these days, I also wonder if we
> shouldn't move the module to kdelibs, so other packages (pimlibs, sdk,
> kdevplatform) can use it without trying to maintain multiple copies.

Yes, I think so. But before that we should check against the current version 
in cmake and make sure it is as similar as possible.

Alex




More information about the kde-core-devel mailing list