Hi Andreas,
On 03.07.08 12:23:11, Doug Gregor wrote:
On Tue, Jul 1, 2008 at 1:24 PM, Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
(7)
I couldn't understand the dicotomy between the cached and non-cached
versions of the include dirs:
Boost_INCLUDE_DIRS vs Boost_INCLUDE_DIR
What's the choice for? What doesn't the library dir, or for that matter,
the
libraries list offer the same choice?
I actually don't know why this is the why it is, sorry.
I'll try to read the rest later and answer everything, but for now just
this: The module needs to be fully backwards compatible to the CMake 2.4
version (thats why it was included in 2.6.0), and in cmake 2.4 you had
only 2 variables, one for include dirs one for library dirs and did
something like
link_directories( ${Boost_LIBRARY_DIRS} )
target_link_libraries( foo boost-thread )
Hmm, this explains why there is a cached Boost_INCLUDE_DIRS and a
memory-onlu Boost_INCLUDE_DIR?
If so I don't get it.. can you elaborate?
Andreas
(9)
It is documented that this requires CMake 2.5 (which is 2.6 for us end
users). And later overdocumented that this ships with CMake 2.6 so the
version is always right.
Well, strictly speaking one can use *this* module with earlier cmake
versions, such as 2.4.7 which is still largely used in many linuxes, by
emulating the additional find_package feautres.
That is, instead of calling it like:
find_package(Boost 1.37.1 COMPONENTS thread )
call it like this:
set( Boost_FIND_VERSION 1.37.1 )
set( Boost_FIND_VERSION_MAJOR 1 )
set( Boost_FIND_VERSION_MINOR 37 )
set( Boost_FIND_VERSION_PATCH 1 )
set( Boost_FIND_COMPONENTS thread )
find_package(Boost)
which works just the same with the old find_package (this is in fact
what
I'm doing in CGAL to avoid requiring users to install CMake 2.6 which is
usually not just a simple apt-get/rmp call in many linuxes)
I'm not quite sure what to do about this... with the FindBoost we ship
in CMake 2.6.1, we should take advantage of CMake's features (e.g.,
the new HINTS feature, which eliminates a bunch of redundant code).
The reason its so backwards compatible is that I wanted to be
kdevplatform's (kde module) copy to be as similar as possible (and that
one needs to work with cmake 2.4) so that later when KDE depends on
CMake 2.6 I'll have to do as little porting of our find-boost-code as
possible.
In fact, I've tested it with 2.4.7, 2.4.8 and 2.6 amd it just worked (with
the versioning detail I explained in my response to Doug)
Best
Fernando
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
