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-08 06:37:14

On 2016-03-08 07:18, Rene Rivera wrote:
>
> 1. Some people don't fancy auto-linking.
>
> 2. People responding with "+N".. Which of the following would you prefer?

I wasn't responding before but let me add my references.

> And give rationale for your preference, and optionally give rationales for
> not preferring others:
>
> A) Having file names with "32" *and* "64" on them?

This would be an ok solution, although not the best.

> B) Having current names indicate 32 and adding "64" to file names otherwise?

Please no. This makes the current names ambiguous to someone not 
familiar with the convention. And why the 32-bit version should be the 
default?

> C) Having current names indicate the "default" system address-model and add
> "32" or "64" to indicate the non-default?

No. This ties naming with the default in Boost.Build, which hopefully 
will change to 64-bit at some point.

> D) Having the current names and placing 32 bit address-model variants in
> "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install
> location)

Out of the proposed variants, this one I like the most.

> E) Having the current names and placing 32 bit address-model variants in
> "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)

No. Same argument as for B.

> F) Having the current names and placing the "default" system address-model
> variants in "stage/lib" and the non-default in "stage/lib32" or
> "stage/lib64"? (Equivalently for install location)

No. Same argument as for C.

I think another option is missing here, and I would like this option the 
most:

G) Put libraries to a subdirectory named according to the architecture, 
e.g. "stage/i686", "stage/x86_64", "stage/armhf", etc. I'm not sure how 
install target works on Windows, but the target install directories 
should also correspond to the architecture of the binaries.

This would solve the problem with cross-compilation in general and not 
just the special case of 32 and 64-bit x86.

I prefer using architecture tag in the directory name rather than the 
file name because it makes setting up users' projects easier and doesn't 
require changes to auto-linking. This is also the approach taken in 
operating systems, including Windows and Linux.