The names of the directories holding the per-platform libs & dlls for Windows, x86_32 and x86_64, do not match the names provided by macros in a wide range of MSVS versions. Those names are Win32 and x64 and are the values of $(PlatformName) in all versions of MSVS since 64-bit was introduced and $(Platform), available since MSVS 2008.
The only macro available to use with the current naming scheme is $(PlatformArchitecture) which has values of 32 or 64. That is available in MSVS 2013 but not in MSVS 2008. I do not have 2010 or 2012 so I cannot confirm when it was introduced.
Being able to use macros makes it easier to set up build systems and is critical when using GYP because in GYP it is not possible to provide per-configuration/platform library names or directories.
[blockquote]do not match the names provided by macros in a wide range of MSVS versions[/blockquote]
This is by design. The folder names of our binary deliverables (GUI, CLI, libraries and plugins) are in the form operatingsystem_instructionset_bits
[blockquote]This is by design. The folder names of our binary deliverables (GUI, CLI, libraries and plugins) are in the form operatingsystem_instructionset_bits[/blockquote]
I am sure it is and I am sure the consistency was found appealing. However it is more helpful to name things using the conventions of each platform, as it fits better with the platform tools, than maintain a consistency of naming across all platforms. The old saying “a foolish consistency is the hobgoblin of little minds” comes to mind.
Note I do not mean to to imply that anyone there has a little mind, only that I find this a foolish consistency. Whenever I think of those words the rest of the expression leaps to mind.
I once used a similarly consistent naming scheme myself but when I realized it was causing me to make unnecessary edits to project files, I stopped.
Naming the directories after the appropriate operating C defines could be useful. This would be quite straightforward for Windows. However, it would be more complex for other targets such as the various Android ABIs (Windows x86 32 and 64 bit binaries would sit at one depth, Android binaries would probably end up two levels deep). These complications are why we chose to define our own concise convention.
We will take the feedback on board, but until there is a high demand for the change it will remain low priority for us.
