MantisBT - CMake
View Issue Details
0008099CMakeModulespublic2008-11-14 06:042009-02-23 22:52
Markus Schwarzenberg 
Philip Lowman 
normalmajoralways
closedfixed 
CMake-2-6 
CMake-2-6 
0008099: Fix for UNC-Path issues
FindBoost.cmake (cmake-2.6.2, windows) gives incorrect paths in
     Boost_LIBRARY_DIRS
and Boost_<component>_LIBRARY

when boost is installed at a UNC-Path based location.
The UNC-Paths get truncated too much, for example
  //server/share/
is converted to
  /server/share/
(which is not an UNC-Path).

The attached patch fixes this.
Example:

set(BOOST_ROOT "//server/share/sw/win32/boost_1_36_0")
FIND_PACKAGE(Boost REQUIRED COMPONENTS thread)

Resulting CMakeCache.txt - variables (original FindBoost module)

  Boost_LIBRARY_DIRS:FILEPATH=optimized;/server/share/sw/win32/boost_1_36_0/lib/boost_thread-vc80-mt-1_36.lib;debug;/server/share/sw/win32/boost_1_36_0/lib
  Boost_THREAD_LIBRARY:FILEPATH=optimized;/server/share/sw/win32/boost_1_36_0/lib/boost_thread-vc80-mt-1_36.lib;debug;/server/share/sw/win32/boost_1_36_0/lib/boost_thread-vc80-mt-gd-1_36.lib

Resulting CMakeCache.txt - variables (patched FindBoost module)

Boost_LIBRARY_DIRS:STRING=//server/share/sw/win32/boost_1_36_0/lib
Boost_THREAD_LIBRARY:STRING=optimized;//server/share/sw/win32/boost_1_36_0/lib/boost_thread-vc80-mt-1_36.lib;debug;//server/share/sw/win32/boost_1_36_0/lib/boost_thread-vc80-mt-gd-1_36.lib
No tags attached.
diff FindBoost.cmake.diff (1,170) 2009-01-15 03:41
https://public.kitware.com/Bug/file/1990/FindBoost.cmake.diff
Issue History
2008-11-14 06:04Markus SchwarzenbergNew Issue
2009-01-07 14:26Bill HoffmanStatusnew => assigned
2009-01-07 14:26Bill HoffmanAssigned To => Douglas Gregor
2009-01-15 02:45Philip LowmanNote Added: 0014565
2009-01-15 03:41Markus SchwarzenbergFile Added: FindBoost.cmake.diff
2009-01-15 03:45Markus SchwarzenbergNote Added: 0014569
2009-01-15 03:57Markus SchwarzenbergNote Added: 0014570
2009-01-15 08:27Philip LowmanNote Added: 0014572
2009-01-18 14:42Philip LowmanNote Added: 0014602
2009-01-18 14:42Philip LowmanAssigned ToDouglas Gregor => Philip Lowman
2009-01-18 14:42Philip LowmanStatusassigned => resolved
2009-01-18 14:42Philip LowmanResolutionopen => fixed
2009-02-23 22:52Philip LowmanNote Added: 0015315
2009-02-23 22:52Philip LowmanStatusresolved => closed
2009-02-23 22:52Philip LowmanFixed in Version => CMake-2-6

Notes
(0014565)
Philip Lowman   
2009-01-15 02:45   
The patch didn't make it, can you reupload?
(0014569)
Markus Schwarzenberg   
2009-01-15 03:45   
Sorry about the missing upload, now it is there.
Note: this is a workaround for the cmake-problem described in

http://www.cmake.org/pipermail/cmake/2008-November/025317.html [^]
(0014570)
Markus Schwarzenberg   
2009-01-15 03:57   
I've just created a separate issue for the underlying cmake-problem:

http://public.kitware.com/Bug/view.php?id=8378 [^]
(0014572)
Philip Lowman   
2009-01-15 08:27   
Thanks for creating the bug entry for the other problem and linking it here.

Since Boost_XXX_LIBRARY contains a list of optimized and debug keywords as well as two libraries, it's ultimately doing nobody any good as a FILEPATH (can't use the cache to "select" multiple files), so it might as well be made into a STRING, especially if it fixes your problem too.

Thanks for noticing the Boost_LIBRARY_DIR ugliness, I'll merge in your fix for that as well. Noticed while triaging yesterday you aren't the only one that's pointed this out (see: http://public.kitware.com/Bug/view.php?id=7864 [^] )

The underlying cmake problem still needs to be fixed in the C++ code, however, until then you're going to have similar problems with nearly every find module.
(0014602)
Philip Lowman   
2009-01-18 14:42   
Checked in. Boost_LIBRARY_DIR and Boost_XXX_LIBRARY are strings now on WIN32, I left them as FILEPATH on non-WIN32.

Committer: Philip Lowman <philip@yhbt.com>
/cvsroot/CMake/CMake/Modules/FindBoost.cmake,v <-- FindBoost.cmake
new revision: 1.19; previous revision: 1.18
(0015315)
Philip Lowman   
2009-02-23 22:52   
Underlying CMake issue 0008378 was resolved in 2.6.3. The temporary workaround for the issue I mentioned was removed prior to the 2.6.3 release.

Thanks for the bug report.