[CMake] FindBoost: find both win32 and x64 static libs

Dmytro Ovdiienko dmitriy.ovdienko at gmail.com
Wed Dec 15 08:53:17 EST 2010


Philip,

I like it. That is exactly I tried to achieve with BOOST_LIBRARYDIR. However
BOOST_LIBRARYDIR does not support list values in the CMake 2.8.2.

On 7 December 2010 15:16, Philip Lowman <philip at yhbt.com> wrote:

> On Sunday, December 5, 2010, Hicham Mouline <hicham at mouline.org> wrote:
>
>  > I've built both win32 and x64 versions of boost thread library with the
> > following 2 lines:
> >
> > 1. 32bit cl.exe from msvc9 directory in the %PATH%
> > bjam --with-thread --layout=versioned toolset=msvc address-model=64
> > variant=release link=static threading=multi runtime-link=shared
> >
> > 2. 64bit cl.exe from msvc9 directory in the %PATH%
> > bjam --with-thread --layout=versioned toolset=msvc address-model=64
> > variant=release link=static threading=multi runtime-link=shared
> >
> > however, the resulting .lib files have identical names however:
> > libboost_thread-vc90-mt-1_44.lib
> > libboost_thread-vc90-mt.lib
> >
> > Dmytro, there is no distinction between 32bit and 64bit. The 64bit lib
> size
> > is approximately double the 32bit lib.
> >
> > boost-build, how to change this to include the bitness in the boost lib
> > name?
> > If it's impossible, Philip, perhaps FindBoost could be changed to allow
> for
> > different directories under BOOST_ROOT for the lib directories, something
> > like lib\win32 and lib\x64 or whatever names can be agreed on.
>
> If the user is compiling 32-bit code I could make FindBoost search "lib32"
> before "lib" and for 64-bit code I can make it search "lib64" before "lib".
>  If the user had an empty lib64 directory for some reason, it would still
> find the boost libraries in "lib".
>
> Would this work for you?
>
> The BOOST_LIBRARYDIR variable is the only other workaround I can think to
> this issue.
>



-- 
Dmytro Ovdiienko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101215/752f284a/attachment.htm>


More information about the CMake mailing list