[CMake] FindBoost.cmake from 2.6

[Doug Gregor]

Hi Fernando,

On Tue, Jul 1, 2008 at 1:24 PM, Fernando Cacciola
<fernando.cacciola at gmail.com> wrote:
> I'm in charge of the CMake build installation for CGAL (www.cgal.org) and I
> so far had been using my own FindBoost module hoping to get rid of it as
> soon as the official module got improved.
>
> While the latest FindBoost is a significant improvement over the previous
> version, there are still a few issues with it:

Thanks for reporting these.

> (1)
> It should use $ENV{ProgramFiles} instead of "C:\Program Files"

Okay, fixed.

> (2)
> If you google for both "BOOSTROOT" and "BOOST_ROOT" you'll find that both
> enviroment variables are equally used among the large boost users community,
> thus I would suggest to use both in the module. In particular, CGAL had long
> been using BOOSTROOT, and I'd hate to tell our users to rename that.

Okay.

> (3)
> The following logic:
>
>   IF( WIN32 )
>     SET(_boost_INCLUDE_SEARCH_DIRS ${BOOST_ROOT}
> ${_boost_INCLUDE_SEARCH_DIRS})
>   ELSE( WIN32 )
>     SET(_boost_INCLUDE_SEARCH_DIRS ${BOOST_ROOT}/include
> ${_boost_INCLUDE_SEARCH_DIRS})
>   ENDIF( WIN32 )
>
> is indeed correct and needed since on windows the root folder is itself the
> include folder.
>
> However, this logic is used for the case of the CMake variable BOOST_ROOT,
> but not for the enviroment variable BOOST_ROOT
> (this in fact causes the search to fail in my machine when I arrange it to
> depend solely on the enviroment variable BOOST_ROOT)
>
> I suggest to unify the code by doing:
>
> if ( NOT BOOST_ROOT AND NOT $ENV{BOOST_ROOT} STREQUAL "" )
>  set( BOOST_ROOT $ENV{BOOST_ROOT) )
> endif()
>
> if ( NOT BOOST_ROOT AND NOT $ENV{BOOSTROOT} STREQUAL "" )
>  set( BOOST_ROOT $ENV{BOOSTROOT) )
> endif()
>
> file(TO_CMAKE_PATH ${BOOST_ROOT} BOOST_ROOT)
>
> and then just proceed to use BOOST_ROOT as it does now
>
> The same goes for BOOST_INCLUDE_DIR and BOOST_LIBRARY_DIRS

Good, thanks!

> BTW, why is the above path conversion gone in the 2.6 version??

I don't know. I've added it back...

> (4)
> The two loops over _boost_TEST_VERSIONS are nearly indentical, and it's a
> bit complicated, so I would put that in a macro to make it more readable,
> discriminating the search path just around the call to find_path (where it
> matters)

With CMake 2.6.1, the HINTS feature of find_path allows us to collapse
these two loops into a single loop.

> And not just that:
>
> Under windows, boost is installed on a folder of the form "boost_x_y_z", not
> "boost-x_y_z", yet the suffix is constructed as:
>
>      SET(_boost_PATH_SUFFIX
>       boost-${_boost_VER}
>     )
>
> Notice the "boost-" instead of "boost_"

Okay.

> So, on what platforms does this additional version search stuff work? I
> certainly doesn't on my windows machine (yes, I tested it).

It's meant for *nix platforms, where Boost.Build installs headers into
versioned directories.

> (5)
> One can use cygwin to run other compilers besides gcc. In fact, that's what
> we do in CGAL, so this:
>
>  IF (CYGWIN)
>   SET (_boost_COMPILER "-gcc")
>  ENDIF (CYGWIN)
>
> just breaks any previous MSVC detection.
> Since "-gcc" is already the fallback value I would just remove those lines.

Okay.

> (6)
>
> Also, in at least 2.4.7, MSCV80 is incorrectly set for VC90 (besides
> MSCV90), so the MSVC version discrimination should be reversed and nested:
>
>  if ( MSVC90 )
>    ...
>  elseif ( MSVC80 )
>    ...
>  elseif ( MSVC71 )
>    ...
>  endif()

Okay, thanks!

> (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.

> (8)
>
> The "check minimum version" stuff is not working for me because the
> Boost_VERSION_* variables are undefined by the time they are compared to the
> Boost_FIND_VERSION_* requirement.
>
> Does it work for you there?

This has been working for me for a while...

> (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).
Should we maintain a separate version of FindBoost for older versions
of CMake? I don't know, but I'm concerned about the maintenance burden
there, particularly for a complicated module like this one.

Anyway, I'm working on a bunch of issues with FindBoost, and will ping
the list when I think I have it right.

  - Doug