On March 8, 2016 2:36:42 AM EST, Boris Rasin
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)