Build files for Visual Studio 2012 (MSVC 11)

Description

However VS 2010SP1 project files are generally compatible with VS 2012 but for the sake of consistency and to enable incorporation of enhancements of VS development environment in the future, it would be good to create separate project files for VS 2012.

Changes made (some rafactoring):

Platform Toolset changed to Visual Studio 2012

All parameters related to wxWidgets are consolidated in one property file 'wx_vc11_wx_setup.props' as a set of VS properties (version info, paths, file names, prefixes, suffixes, etc.)

This property file is included in all project files and all wxWidgets-related properties are exposed to the projects as User Macros.

All paths and file names in the project files are not hard-coded but determined by MSBuild as a combination of project macros (with pattern the same as used in 'mswc\wx\setup.h' header file)

Advantages:
To change any wxWidgets parameter in the future (like version string), it will be necessary to modify only one property file instead of (almost) all project files.

This is nice but I'd still like very much to be able to generate these files automatically, maintaining them by hand is so painful. But if we can't do this even with the new version of bakefile, then we should use these projects.

In any case, thanks a lot for your work!

P.S. Note to self: this is also an example of a .props file that bakefile should be capable of generating (but isn't, currently).

Just an additional question: is it possible to edit these user macros from the IDE? I must be missing something but I can't find any way to do it... It would be nice if people could change them directly in the project options (even if I agree that changing them in a single .props file is already a big progress compared to having to edit all the project files).

Right click on 'wx_vc11_wx_setup' and select Properties option ('wx_vc11_wx_setup Property Pages' should appear)

Click 'User Macros' on the left pane

To edit a macro you need to double click selected item.

Please note that some macros are shared among many configurations (some are even common for all) and if you change macro value for one configuration it can be propagated to others.
Property file is common for all projects so if you change any macro value in one project it will propagated to all.

Thanks, this worked (I tried to find it in the properties window shown from the solution view which IMHO would have been more natural but who I am to dispute Visual Studio UI decisions...). And it's indeed very nice to be able to change, say, compiler prefix in a single place only.

I guess we should add these files (and their "_vc12" versions for MSVS 2013?) to the 3.0 branch as the switch to bakefile 1.x won't happen there anyhow, what do people think?

I think it's a good idea to add also project files for VS 2013 to the next release.
VS 2012 and VS 2013 project files are compatible (at least for C++ projects) so there should be OK to copy wx_vc11 files to wx_vc12 ones.

It would be only necessary to change following tag in all wx_vc12*.vcxproj files:
from <Import Project="wx_vc11_wx_setup.props" />
to <Import Project="wx_vc12_wx_setup.props" />

Another thing that could be changed in wx_vc12*.vcxproj files is a tag holding Platform Toolset value:

in _vc11 files this is <PlatformToolset>v110</PlatformToolset>

in _vc12 files could be <PlatformToolset>v120</PlatformToolset>

But honestly, I don't know how it really affects VS behaviour. Everything will work even if you decide to left it intact.

OK, I'm going to commit this as we are clearly not going to have bakefile-generated projects any time soon and we do need to let people build with VC 11/12 simpler. It is going to be painful to maintain VC10, VC11 and VC12 projects manually though, it feels like a return to the dark ages :-(

Anyhow, please test building with them and let us know about any problems.

One small problem I see with these files is that *setup.props are under version control but I'm going to be modifying it all the time, i.e. I have vc120 as wxCompilerPrefix instead of the default vc. Does anybody know of a way to allow to keep these files locally modified without checking them in? Otherwise I'm all but certain that I'm going to do it sooner rather than later...

One small problem I see with these files is that *setup.props are under version control but I'm going to be modifying it all the time, i.e. I have vc120 as wxCompilerPrefix instead of the default vc.

I think the best way is to override the properties in a separate user config file which is imported by the props file if it exists (i.e. something like <Import Project="$(MSBuildThisFileDirectory)\wx_vc12_wx_setup.user.props" Condition="Exists('$(MSBuildThisFileDirectory)\wx_vc12_wx_setup.user.props')" />). It's also possible to add additional property sheets to the project settings UI, which stores the values in the .vcxproj.user file for that project. Setting properties for more than one project in that way is kinda hacky (I haven't found a better solution than only adding the property sheets to one of the projects and then Importing that project's .vcxproj.user file in the other ones) and the documentation is lacking, but it's otherwise quite nice.

One small problem I see with these files is that *setup.props are under version control but I'm going to be modifying it all the time, i.e. I have vc120 as wxCompilerPrefix instead of the default vc. Does anybody know of a way to allow to keep these files locally modified without checking them in? Otherwise I'm all but certain that I'm going to do it sooner rather than later...

If you need to override e.g. 'wx_vc12_wx_setup.props' file associated with particular project/solution you can try this approach:

Copy this 'wx_vc12_wx_setup.props' file to the folder '%LOCALAPPDATA%\Microsoft\MSBuild\v4.0'

Thanks @awi, this works and it's the simplest thing to do, so I'm happy with it for now. But I also like @plorkyeran's idea as it would be easier to use for others, especially if we named the files in some clear way (e.g. wx_std.props and wx_local.props or something like that). If the projects could be updated to take into account such local props files if they exist, it would be perfect.

That idea that project files should be ready to import user/local properties from the file is fine. Unfortunately, all project files must be modified to implement this feature.
Corresponding patch is attached (it assumes 'wx_local.props' as a filename of property file).

Sorry, I'd like to return to this because while testing 3.0.1 builds I realized that these project files have a problem: they seem to always rebuild everything. E.g. after a full (successful) build, building again recompiles all the files once more.

Any idea what could be causing this? IME this is usually due to some non-existence dependency, which MSVS tries to create by building (and fails), but I don't see any such dependencies here...

We want to generate debug information even in the release builds of the
libraries in order to allow debugging of the programs using them. This is
especially important for the DLLs but do it for the static release build too
for consistency.

This also almost fixes the constant rebuilding of the entire solution which
happened because the PDBs, supposed to be generated by linker, were not found
because they were not actually created as the debug information wasn't there.

We want to generate debug information even in the release builds of the
libraries in order to allow debugging of the programs using them. This is
especially important for the DLLs but do it for the static release build too
for consistency.

This also almost fixes the constant rebuilding of the entire solution which
happened because the PDBs, supposed to be generated by linker, were not found
because they were not actually created as the debug information wasn't there.