Opened 11 months ago

Closed 9 months ago

Last modified 9 months ago

#15780 closed enhancement (fixed)

Build files for Visual Studio 2012 (MSVC 11)

Reported by: awi Owned by:
Priority: low Milestone: 3.0.1
Component: build Version: 3.0.0
Keywords: bakefile msvc project Cc:
Blocked By: Blocking:
Patch: yes

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.

Family of vx_vc11* files is attached in the patch file.

Attachments (2)

wx_vc11.zip download (82.0 KB) - added by awi 11 months ago.
Patch file is zipped due to the large size of the file
msvc-build.patch download (33.5 KB) - added by awi 9 months ago.
Modifications to the project files.

Download all attachments as: .zip

Change History (24)

Changed 11 months ago by awi

Patch file is zipped due to the large size of the file

comment:1 Changed 11 months ago by vadz

  • Component changed from wxMSW to build
  • Keywords bakefile msvc project added
  • Milestone set to 3.0.1
  • Priority changed from normal to low
  • Status changed from new to confirmed

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

comment:2 Changed 11 months ago by vadz

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

comment:3 Changed 11 months ago by awi

To get access to User Macros from UI you should go this path:

  • Open Property Manager via View -> Other Windows -> Property Manager
  • Expand branch for any project
  • Expand branch for selected configuration
  • 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.

comment:4 Changed 11 months ago by vadz

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?

comment:5 Changed 11 months ago by awi

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.

comment:6 Changed 11 months ago by vadz

Yes, the toolset definitely needs to be changed, but this is easy to do and MSVS actually can do it on its own. I've already created vc12 projects here and they seem to work fine.

comment:7 Changed 11 months ago by awi

Please check also if second line in wx_vc12.sln file is set by MSVS to
# Visual Studio 2013

comment:8 follow-up: Changed 9 months ago by vadz

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

comment:9 Changed 9 months ago by VZ

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [75925]) Add projects for MSVC 11 and 12 (MSVS 2012 and 2013).

Add manually created projects for now, as it looks that we are not going to
have bakefile-generated ones any time soon.

Closes #15780.

comment:10 Changed 9 months ago by VZ

(In [75926]) Add projects for MSVC 11 and 12 (MSVS 2012 and 2013).

Add manually created projects for now, as it looks that we are not going to
have bakefile-generated ones any time soon.

Closes #15780.

comment:11 Changed 9 months ago by plorkyeran

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.

comment:12 in reply to: ↑ 8 Changed 9 months ago by awi

Replying to vadz:

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:

  1. Copy this 'wx_vc12_wx_setup.props' file to the folder '%LOCALAPPDATA%\Microsoft\MSBuild\v4.0'
  2. Modify properties in this file as you need.
  3. Import this property file into e.g. 'Microsoft.Cpp.Win32.user' file by adding following XML element: <ImportGroup Label="PropertySheets">

<Import Project="wx_vc12_wx_setup.props" />

</ImportGroup>

  1. You can modify also other configuration files, like 'Microsoft.Cpp.x64.user', etc.

One has to take into account that properties imported this way are global for all projects/solutions for the user.

comment:13 Changed 9 months ago by vadz

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.

Changed 9 months ago by awi

Modifications to the project files.

comment:14 Changed 9 months ago by awi

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

comment:15 Changed 9 months ago by VZ

(In [75982]) Use settings in wx_vcN_local.props files if they exist.

Allow overriding the default build settings in local properties files for VC11
and VC12 builds.

See #15780.

comment:16 Changed 9 months ago by vadz

Thanks again for doing all this!

comment:17 Changed 9 months ago by vadz

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

comment:18 Changed 9 months ago by vadz

I found the answer thanks to this hint, see the upcoming commits for the details if you're curious.

comment:19 Changed 9 months ago by VZ

(In [76064]) Add missing XRC handlers to the manual VC{11,12} projects.

XRC handler in aui, ribbon and richtext libraries were omitted in the initial
versions of the projects for some reason.

See #15780.

comment:20 Changed 9 months ago by VZ

(In [76065]) Enable debug information in release configuration of MSVC{11,12} projects.

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.

See #15780.

comment:21 Changed 9 months ago by VZ

(In [76067]) Add missing XRC handlers to the manual VC{11,12} projects.

XRC handler in aui, ribbon and richtext libraries were omitted in the initial
versions of the projects for some reason.

See #15780.

comment:22 Changed 9 months ago by VZ

(In [76068]) Enable debug information in release configuration of MSVC{11,12} projects.

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.

See #15780.

Note: See TracTickets for help on using tickets.