Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-04-24 05:05:29

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Mateusz Loskot
> Sent: 24 April 2015 08:43
> To: boost_at_[hidden]
> Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
> 
> On 24 April 2015 at 00:07, Asbjørn <lordcrc_at_[hidden]> wrote:
> > On 23.04.2015 22:28, Vladimir Prus wrote:
> >>
> >> Is this problem unique to Boost? Does any other library encode 32 vs
> >> 64 bit variant in library name?
> >
> > The OSS project I'm involved with depends directly on Boost, Python, Qt,
> > OpenEXR, FFTW and Embree. On Windows we don't use any 32/64 bit variations
> > of the filenames of any of our libraries.
> >
> > Instead we keep two separate directory trees for 32bit and 64bit
> > dependencies, everything from source to lib/dll files.
> 
> FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use
> and what, hopefully, is becoming a de-facto standard on Windows.

As a solution, this sounds acceptable, but IMO Boost build needs to deal with it and the instructions need to tell users how to do it.  Can any experienced users provide some notes on this, perhaps using Trac which is freely editable?

However, all solutions seem liable to cause users more than a little grief.

Paul

PS I also agree that the default build on 64-bit systems should be 64 bit, but this might be a 'breaking change' for many, so there should be some clear warning that this will happen.

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]