Boost logo

Boost :

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-04-23 16:58:17


On Thursday 23 April 2015 23:28:54 Vladimir Prus 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 <
> >>
> >> 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.
> >> 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? Does any other library encode 32 vs 64 bit
> variant in library name?
>
> 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.
>
> So why is Boost special?

Boost is not special. Basically, every project deals with it in its own way on
Windows (or just doesn't). The problem is that in Windows infrastructure there
is no canonical library layout for different architectures, and Boost doesn't
offer its own layout. This means CMake devs can't put anything sensible in
Boost library lookup routines so that it at least sometimes work.

I think most projects simply put the built binaries in different directories,
and that's probably what Boost should do. I'd say the name of the directory
should describe the target platform, something similar to what 'dpkg-
architecture -qDEB_BUILD_GNU_TYPE' provides.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk