View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003447CMakeCMakepublic2006-06-26 19:352006-07-21 12:04
ReporterAndrew Maclean 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003447: Find Boost feature request.
DescriptionAttached is a file that finds the boost libraries. I hope this will be a suitable inclusion for CMake.

Thanks
   Andrew
TagsNo tags attached.
Attached Files? file icon FindBoost.cmake [^] (5,765 bytes) 1969-12-31 19:00
? file icon FindBoostCorrectVersion.cmake [^] (5,737 bytes) 1969-12-31 19:00
? file icon FindBoostUpdate1.cmake [^] (5,078 bytes) 1969-12-31 19:00
? file icon BoostConfigUpdate2.cmake [^] (8,132 bytes) 1969-12-31 19:00
? file icon FindBoost_V2.cmake [^] (6,403 bytes) 1969-12-31 19:00
? file icon FindBoost_V3.cmake [^] (6,402 bytes) 1969-12-31 19:00
? file icon FindBoost_V4.cmake [^] (6,356 bytes) 1969-12-31 19:00
? file icon FindBoost_V5.cmake [^] (6,329 bytes) 1969-12-31 19:00

 Relationships

  Notes
(0004364)
Andrew Maclean (reporter)
2006-06-27 00:29

The first file uploaded had an incorrect search path.
So:
1) Ignore FindBoost.cmake
2) Use FindBoostCorrectVersion.cmake. Rename it to FindBoost.cmake.

Thanks

Andrew
 
(0004374)
Brad King (manager)
2006-06-28 13:53

There are a few more issues to discuss:

# Paths to library files.
# IF (WIN32)
# LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
# ELSE (WIN32)
# If your boost libraries are not in the system path, add them to a LINK_DIRECTORIES statement here:
# ENDIF (WIN32)

This should be just plain

# LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

on all platforms. System paths are automatically removed from the link directory list by CMake. A project will not know whether the user building it has installed boost in a system path.

FIND_PATH will automatically search /usr/include and /usr/local/include on platforms where they are the convention. See its documentation for the CMAKE_SYSTEM_INCLUDE_PATH variable. Are you adding /usr and /usr/local because boost is somtimes installed under /usr/boost/config.hpp? I doubt it.

Why do you strip a trailing "/boost" from the path? It will not be included in the value of Boost_INCLUDE_DIR because the file is called boost/config.hpp.
(0004387)
Andrew Maclean (reporter)
2006-06-28 21:08

Thanks for your comments.
I have:
Removed the code that strips the trailing boost.
Changed the variable BOOST_DIR_SEARCH to have the values C:/C:/boost/include
and remived the include/ from the suffixes in SUFFIX_FOR_PATH, also removed the /usr, /usr/local paths in FIND_PATH in the light of your comments.

Andrew
(0004416)
Brad King (manager)
2006-07-07 17:26

I just tried the Update1 version. It looks like the logic for deciding what kind of message to produce at the bottom is a bit off. A FATAL_ERROR should be produced only if REQUIRED was given. A warning may be produced only if QUIETLY was NOT given.

Have you thought about trying to find boost build trees? I don't think boost has to be installed to be used.
(0004424)
Andrew Maclean (reporter)
2006-07-10 06:28

Ok I think the logic is correct for the error messages at the bottom of the code. By the way, I copied this from FindVTK.cmake so I think the logic there may be off.

Thanks for your suggestion regarding finding the build trees.

I have modified the code to try to find the boost build trees but the solution depends upon the user staging the libraries. I have also added a provision for the user to set a BOOST_PATH variable either in the calling CMakeLists.txt file or as an environment variable.

Finding the build trees is difficult as explained below, so I would prefer using bjam to stage the libraries. Here is an explanation plus a bit on how FindBoost.cmake works now:

With respect to include directories, there is not a great problem in that the structure is the similar in the source and in the installed version.

However, Boost has a particularly complicated structure with respect to building libraries.
This is exemplified by the following paths:

${BOOST_ROOT}/boost-<version>
/bin/boost/libs/<library>/build/<library.dll>|lib<library.lib>/<compiler>/<debug>|<release>/<threading-multi>|<runtime-link-static>
In the case of thread it is further complicated (there are extra subdirectories):
${BOOST_ROOT}/boost-<version>
/bin/boost/libs/<library>/build/<library.dll>|lib<library.lib>/<compiler>/<debug>|<release>/<threading-multi>
${BOOST_ROOT}/boost-<version>
/bin/boost/libs/<library>/build/<library.dll>|lib<library.lib>/<compiler>/<debug>|<release>/<runtime-link-static>/<threading-multi>

Where ${BOOST_ROOT} is where you unpacked the source files and <compiler> is the toolset being used, e.g VC8.0 – currently there are some 28 supported toosets.

It may be possible to modify the script to handle all of these cases but given that bjam provides a stage and install option that gathers all the library files together, I hardly think it is worth the effort.

Bjam provides two options, “install” where the libraries are installed in the system and “stage” where the libraries are gathered and staged into a common directory. Users should select either one of these options because these options ensure that all the libraries have been gathered together and are in a common location.

The stage process creates a directory called “stage” in the source folder which has a subdirectory called lib where all the library files are gathered.
The install process copies the contents of the “stage/lib” directory to c:\boost\lib and c:\boost \include in the case of Windows. A similar process happens in Linux except the files are copied to /usr/local/lib and usr/local/install.

So I am proposing that FindBoost should use the optional variable BOOST_ROOT. This can be set in the calling CMakeLists.txt file to find the boost includes and libraries, or it can be set as an environment variable.

So FindBoost now works like this:

FindBoost first looks for a variable called BOOST_PATH set by the users CMakeLists.txt file that calls this script. If this is set then it uses this to establish paths to the include directory and library directory.
If this is not set, then FindBoost will look for an environment variable called BOOST_PATH and, if it exists, use this to establish paths to the include directory and library directory.
If BOOST_PATH has not been set either in CMakeLists.txt or as an environment variable, then FindBoost will search in the standard install paths.

This should then set:
  If staged, or the user hasn't installed boost:
     Boost_INCLUDE_DIR to be ${BOOST_ROOT}
   and
     Boost_LIBRARY_DIR to be ${BOOST_ROOT}/stage/lib

   If boost is installed, or the files were copied to some other directory, we get:
     Boost_INCLUDE_DIR to be ${BOOST_ROOT}/include/boost<-version>
   and
     Boost_LIBRARY_DIR to be ${BOOST_ROOT}/lib

Where BOOST_ROOT is something like: /usr, /usr/local,/home/<username>/Boost/boost_1_33_1, c:\boost,c:\boost\boost-1_33_1 etc.

In Windows, we make the assumption that, if the Boost files are installed, the default directory will be C:\boost.



(0004453)
Jan Woetzel (reporter)
2006-07-14 07:19

rename vars.

I think the variable names should be changed to
- Boost_INCLUDE_DIR - for Boost_INCLUDE_DIRS
- Boost_LIBRARIES - for Boost_LIB_DIRS
for consistency reasons.
See Modules/readme.txt

Jan.
(0004454)
Jan Woetzel (reporter)
2006-07-14 07:29

Sorry, _LIBRARIES / _LIB_DIRS was a typo.

I noticed that
readme.txt does not mention an agreed name for link directories and teh singular(plural mixing is annoying but nice for backward compatibility.

Brad,
can you add a note about a desired variable name for link_directories in Modules/readme.txt ?

I have a feeling that findscript "agreed" variable names should match the PROPERTEIS names used by e.g. GET_DIRECTORY_PROPERTY.
Thus we want to use
<Foo>_LINK_DIRECTORIES
accepting that it's longer than <Foo>_LIB_DIRS but consistent with PROPERTIES naming.

Jan.
(0004473)
Brad King (manager)
2006-07-18 13:27

I've added the note to the readme:

/cvsroot/CMake/CMake/Modules/readme.txt,v <-- readme.txt
new revision: 1.8; previous revision: 1.7

I just tried out the latest version, and I don't think BOOST_ROOT is handled properly. There is no reason to offer the option of setting it in the CMake cache because it is harder to explain, and the user can just set Boost_INCLUDE_DIR in the cache anyway. I think the script should use $ENV{BOOST_ROOT} if it is defined to help boost users that already set this variable.

If you want to be able to add an environment variable or CMake variable/cache entry to affect the search, just mention the CMAKE_INCLUDE_PATH variables in the message. You could also reference the FIND_PATH documentation. Most users should just be able to add their boost checkout directory to CMAKE_INCLUDE_PATH and FIND_PATH will locate Boost_INCLUDE_DIR by utilizing the PATH_SUFFIXES option.
(0004495)
Andrew Maclean (reporter)
2006-07-18 21:55

OK done. Also I have updated the documentation. There is a little bit of extra code because if the user sets an environment vatiable BOOST_ROOT then it points to the root of include and lib dirs for Boost, so we just need to:
1) Test for existence,
2) Change \ to /
3) append /include to it.

Andrew
 
(0004501)
Brad King (manager)
2006-07-19 15:01

For converting the slashes in BOOST_ROOT look at the FILE(TO_CMAKE_PATH) command.

In option #1 at the top, the user should set Boost_INCLUDE_DIR, not Boost_INCLUDE_DIRS.

In the notes, there should be no policy difference between Linux and Windows or other platforms. This module will be used by CMakeLists.txt file authors which should run on all platforms.

Is there a list of all boost libraries that may be available? We should probably do a FIND_LIBRARY for each one to get the full path. Then Boost_LIBRARY_DIRS does not need to be used at all.

See the way this is done for Qt and in the upcoming FindwxWidgets module in bug 0003443.
(0004502)
Andrew Maclean (reporter)
2006-07-19 20:48

Fixed as requested.

However I am not sure what you mean by policy differences between Linux and Windows. The only thing I can see in the documentation is the use of both windows and linux paths. This was deliberate as users moving from one platform to another often have difficulties relating to path conventions.

As far as I know there is no list of all available Boost libraries. There is certainly nothing in the include or lib directory.

I don't think it is necessary to list every library in Boost for the following reasons:
1) In Windows, the necessary library is automatically linked through the use of autolinking where the header knows what library to link in.
2) In my experience, you only generally use a few of the libraries. Maybe two or three in the one application. This is not the same as wxWidgets where you generally use a lot of the libraries at once.
3) I have some concerns about the length of the linker command line given that very few libraries will actually be used.


However ... if you reeally want ... I could have a go at doing this. Or we could put it down as something to do in the future if there are some requests for it.

I have had a look at the wxWidgets one in the bug tracker, and I am using it myself. It is very elegant.



(0004503)
Brad King (manager)
2006-07-20 09:25

This is the policy difference I was mentioning:

# Note:
# 1) If you are just using the boost headers, then you do not need to use
# Boost_LIBRARY_DIRS in your CMakeLists.txt file.
# 2) If you are using Linux, and the boost libraries are in the default
# system library paths then you do not need to use Boost_LIBRARY_DIRS.
# 3) If Boost has not been installed, then when setting Boost_LIBRARY_DIRS
# the script will look for /lib first and, if this fails, then for /stage/li
b.

The author of the CMakeLists.txt file does not know whether the user is running on Linux.

As far as the list of libraries I did not mean to look for a file with a list in it. Instead I meant that the Find script should know ahead of time that there are libraries called "boost_A" and "boost_B" and look for them. When the libraries are linked with a full path then dependency chaining is automatic and there is no need to export a set of link directories from the project that includes the boost directory. However this can be added later as you point out.
(0004521)
Andrew Maclean (reporter)
2006-07-20 18:44

I have removed note 2 and put the need to find the libraries as a todo.
(0004523)
Brad King (manager)
2006-07-21 12:04

I've committed the latest version to CVS:

/cvsroot/CMake/CMake/Modules/FindBoost.cmake,v <-- FindBoost.cmake
initial revision: 1.1

We'll include it in CMake 2.4.3.
(0004524)
Brad King (manager)
2006-07-21 12:04

Oh, and thanks for your contribution!

 Issue History
Date Modified Username Field Change


Copyright © 2000 - 2018 MantisBT Team