Re: [boost] 32/64 library name conflict under Windows?

Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-03-09 16:22:18

On 2016-03-09 23:06, Klaim - Joël Lamotte wrote:
> On 9 March 2016 at 20:49, Rob Stewart <rstewart_at_[hidden]> wrote:
>
>> On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <mjklaim_at_[hidden]>
>> wrote:
>>> On 9 March 2016 at 10:35, Paul A. Bristow <pbristow_at_[hidden]>
>>> wrote:
>>>
>>>> If some people want to split into arch-based folders /x86 /x64 /arm
>>> ...,
>>>> then can't they easily do this at library build time
>>>>
>>>
>> http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#install-boost-build
>>>>
>>>> "To use a different directory pass the
>>>>   --stagedir=directory
>>>> option to b2."
>>>>
>>>> A few typical build command lines could be provided to help?
>>>>
>>> If arch type is not somewhere by default (that is, boost distribution
>>> officially put these files somewhere clear
>>> and identifiable), it means that the tools can't rely on a specific
>>> path to find the right binaries.
>>
>> What tools rely on Boost to put libraries in some official location?
>>
>>
> CMake's FindBoost.cmake module which is distributed with CMake for example.
>
> Several times in the past I built a boost version with default location (or
> got the binary distribution)
> and setup my project using CMake to use Boost. Then I get link time errors
> because I was compiling in 32bit
> (I use both 32 and 64bits in most of my projects) and Boost only existed in
> the native platform's architecture version.
> To help me remember about this issue, I setup a specific CMake macro in all
> my projects (which could be
> by someone else than me) to force the user at cmake's configure time to
> specify which binaries to use (I use separaet
> folders at the moment to provide the lib directory path to FindBoost.cmake).

Well, whatever we choose to change (the default target directory or file 
names), CMake will need to be updated. Users' scripts too, unless they 
explicitly specify the target directory. Changing the target directory 
would be safer even.