Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2015-04-23 16:37:30
On 23 April 2015 at 22:28, Vladimir Prus <vladimir_at_[hidden]> wrote:
> On 04/23/2015 10:02 PM, mloskot wrote:
>> Klaim - JoÃ«l Lamotte wrote
>>> On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev wrote:
>>>> So my vote is for building 64-bit binaries on a 64-bit system by
>>>> default. This is also consistent with other systems.
>>> Even with that, having no way for tools (like CMake) to identify one
>>> version from the other is problematic when you actually need to support
>>> Both building the OS native binaries and having a convention to identify
>>> both 32 and 64bit versions would help.
>> I second that too.
>> As a user of CMake+Boost tandem, I find the issue a PITA indeed.
> Is this problem unique to Boost?
I don't know.
> Does any other library encode 32 vs 64 bit variant in library name?
I don't know.
> I might not know lot about Windows development, but often library names does
> not encode anything really, and
> there are separate "Program Options" for 32-bit and 64-bit. And on Linux,
> 32-bit and 64-bit is also
> in different places, with library names being the same.
I guess, your observation is valid.
> So why is Boost special?
My complain is more about CMake module FindBoost.cmake.
I'm surprised it doesn't handle not uncommon scenario of building
Boost-based programon 64-bit Unix host but targetting 32-bit architecture.
I posted about it to CMake ml:
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk