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

Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-03-08 04:54:51

On March 8, 2016 2:36:42 AM EST, Boris Rasin <boris_at_[hidden]> wrote:
>On 2016-03-08 6:18 AM, Rene Rivera wrote:
>> 1. Some people don't fancy auto-linking.

It doesn't play well for cross-platform development since linking is treated entirely differently. Otherwise, there's a lot to like.

>> 2. People responding with "+N".. Which of the following would you
>> prefer?

I didn't respond earlier, but I will do so now.

>> 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 is useful to avoid confusion, but it should be generalized to architecture to account for more than just bit width.

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

That leaves room for ambiguity, so I don't like it.

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

That leaves room for confusion as to the default, especially as it could vary with OS.

>> 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)

This has appeal as it means one need only change the library search path. However, once the libraries have been copied out of those directories, one must inspect the binary to know what they are.

>> 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)

That's in keeping with the Linux model. Following precedent isn't a bad thing. Otherwise it has the same benefits and problems as D.

>> 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)

I don't like the "default" notion.

>I would prefer option A. It fits current naming scheme where each 
>available option
>is spelled out explicitly as part of the name: toolset, thread_opt, 
>rt_opt. This would
>just add another option to this list: platform(x86, x64, arm).

+1

>There is another alternative, which will suit better people who don't 
>fancy auto-linking:
>use the composed name for folder and keep library names the same:
>
>vc140-x86-mt-1_60/
>     boost_system.lib
>     boost_thread.lib
>     ...
>
>vc140-x64-mt-1_60/
>     boost_system.lib
>     boost_thread.lib
>     ...
>
>Auto-linking would work exactly as it works now, but for people 
>configuring projects manually
>things will become much easier: specify the same library names for all 
>targets, just a different
>folder to look for libraries per each target.

If the libraries are copied elsewhere, the distinction is lost. Despite the benefits you note, I think that's undesirable.

>This would become even better if option names were to correspond to 
>relevant toolset macro names.
>Than one could also specify the same lib folder for all targets:
>
>boost_1_60_0/lib/$(PlatformToolset)-$(PlatformTarget)-mt-$(Configuration)-1_60/
>
>This would expand into:
>
>boost_1_60_0/lib/vc140-x64-mt-Debug-1_60/
>boost_1_60_0/lib/vc140-x86-mt-Release-1_60/
>etc.

I like all of that, just not the non-unique names that result.

___
Rob

(Sent from my portable computation engine)