Thoughts about configurations and files names in VS

There are many variants of configuration to build a project or solution in VS - VC++, and dependencies get even more complicated. One may want to just pick the desired configuration from the toolbar in the IDE, to say: debug for win32 or release for x64, and expect all will be compiled with the corresponding libraries. This will not be the reality if some effort is not undertaken. Let's see the possibilities:

• Release/Debug or any other custom configuration variant.
• Platform: Win32, x64, etc.
• Compiler version or tool set: VC2013, VC2015, VC2015-XP, and many others.
• Runtime C++ library linking: MTr (static, release), MTd (static, debug), MDr (dynamic, release), MDd (dinamyc, debug)

All of them can be separately set for each of your projects, which then need to be built together. If you are using some variant of make, you will program how to deal with all this variant using that tool, which is probably the best way, although not completely trivially. And what if you are using the IDE to manage your projects? Anyway, you will need to care about the possibility of incompatibilities, with hard to decipher errors from the linker. Even if there are no errors, you may be recompiling a lot more than needed. To deal with that, I have been using some tricks. The last of them is to save the intermediate files in a separate directory for each configuration, so that no unnecessary recompilation occurs. (but that you my want to delete if space in disk is more important to you than the time to recompile):

<IntDir>..\..\..\temp\$(ProjectName)\$(PlatformToolset)_$(Configuration)_$(PlatformShortName)\</IntDir>

It is located completely outside the repository to avoid any confusion. This, unfortunately, does not directly include (yet) a dependency on the Runtime linking type. I find it convenient to have the resulting output files, from any build system, together in an unique directory that is easy to locate, copy, upload, etc.:

<OutDir>../bin/</OutDir>

Of course, now we need a way to avoid overwriting the different variants and to make it human-readable. I use:

<TargetName>$(ProjectName)_$(PlatformToolset)_$(Configuration)_$(PlatformShortName)</TargetName>

which for the nana library will produce something like this:

..\nana\build\bin\nana_v140_Debug_x86.lib

and which can be "consumed" if you include in your project:

<IncludePath>..\..\nana\include\;$(IncludePath)</IncludePath>
<LibraryPath>..\..\nana\build\bin;$(LibraryPath)</LibraryPath>
<AdditionalDependencies>nana_$(PlatformToolset)_$(Configuration)_$(PlatformShortName).lib;%(AdditionalDependencies)</AdditionalDependencies>

Now you can safely select your desired configuration from the IDE without worries about compatibility or unnecessary recompilations most of the time... improvements to come.

All of this is already included in the main nana VS projects , and in the example projects nana-demo which you can quickly copy and adapt to your own project needs.