IMPORTANT: new master files list

[Vadim Zeitlin]

First the TL;DR summary:

Instead of modifying build/bakefiles/files.bkl, please now edit
build/files and run build/upmake afterwards.


Now the explanation: as you know, we have a real problem with our build
system. Bakefile-0 is unmaintained and can't be used to generate neither
VC10+ project files using MSBuild format nor Xcode projects, so we have to
maintain them manually. Bakefile-1 could help with the former problem but
not with the latter and in any case I could never find time to transition
our bakefiles to it. The problem is genuinely difficult and in spite of
discussing it many times, we've never come close to a realistic solution.

And I still don't have any answer to this problem. But I have one for a
much simpler but, in practice, responsible for 90% of the annoyances one:
that of having to manually add (or remove, or rename) files to all the
{make,project} files. In practice, this is by far the most common
modification of the build system which needs to be done and just having to
manually update the 3 versions of each project file (and actually 6 as
MSBuild projects use a separate .filters file) was driving me crazy.

So here is my solution, cobbled together during this week-end when I was
too ill to be doing anything more productive anyhow: upmake. This is a
small and very dumb script which absolutely doesn't pretend to replace
Bakefile or Premake or CMake or anything at all. It just can be used to
update the existing makefiles by synchronizing the sources/headers used in
them with the given ones. Actually right now it doesn't even work with
makefiles but only with project files and with bakefile-0 files.bkl. The
latter one accounted for more than half of the complexity and time of the
script development actually as it's very different from the real makefiles
and it's still not finished, i.e. there are parts of files.bkl which are
not generated. But I don't want to spend more time on this, what counts is
that the lists of files which are going to change in practice are defined
in build/files and both files.bkl and the VC10+ projects are generated from
it. I also should be able to update Xcode projects (especially if Stefan is
interested...) but I haven't done this yet. And, finally, as discussed in a
recent thread about using CMake, maybe people using other build systems can
find this file useful too. I do know that I'll be glad to not have to
update the VC10+ projects manually any more and I hope others will find it
useful as well.

Please let me know if you have any problems with upmake. It should run out
of the box under Unix (it's a Perl script without dependencies on any non
core modules) and it runs under both Cygwin Perl and Strawberry Perl under
Windows and should run under ActivePerl as well, so if you've got any kind
of Perl on your system you shouldn't have any troubles with it. But you
know whom to contact if/when you do.

Thanks,
VZ

[Artur Wieczorek]

In order to simplify maintenance of VS2010+ projects it would be
possible to take advantage of the fact that format of project files for
VS 2010, 2012 and 2013 is the same (at least for C++ projects) and their
content only differs in 'Platform Toolset' setting.

There would be 3 separate solution files (for VS 2010, 2012, 2013) but
only 1 shared set of project files where 'Platform Toolset' would be set
at build process based on 'VisualStudioVersion' parameter taken from the
environment (compiler itself or solution file settings).

Project files implementing this concept are attached ('Platform Toolset'
is determined in 'wx_vc10+_wx_config.props' file which is included in
all project files).

Regards,
AW

[Vadim Zeitlin]

On Tue, 27 May 2014 18:35:37 +0200 Artur Wieczorek wrote:

AW> In order to simplify maintenance of VS2010+ projects it would be
AW> possible to take advantage of the fact that format of project files for
AW> VS 2010, 2012 and 2013 is the same (at least for C++ projects) and their
AW> content only differs in 'Platform Toolset' setting.
AW>
AW> There would be 3 separate solution files (for VS 2010, 2012, 2013) but
AW> only 1 shared set of project files where 'Platform Toolset' would be set
AW> at build process based on 'VisualStudioVersion' parameter taken from the
AW> environment (compiler itself or solution file settings).

This is brilliant and I'm only slightly bitter because I could have
avoided spending almost 5 hours on writing this upmake hack if I knew this
could have been done before :-/

AW> Project files implementing this concept are attached ('Platform Toolset'
AW> is determined in 'wx_vc10+_wx_config.props' file which is included in
AW> all project files).

If it works -- and while I didn't test it yet, I don't see any reason to
doubt that it does -- I don't see any good reason to not do it like this.
Does anybody else?

I'd probably call the projects just wx_$project.vcxproj though, i.e. avoid
using "10+" in their names if they are really version independent. But
other than that this looks good to me. Again, any additional testing and/or
feedback would be welcome though.

Thanks,
VZ

[Artur Wieczorek]

> I'd probably call the projects just wx_$project.vcxproj though, i.e. avoid
> using "10+" in their names if they are really version independent. But
> other than that this looks good to me. Again, any additional testing and/or
> feedback would be welcome though.
>
> Thanks,
> VZ
>

Attached you can find project files with new naming.
Common configuration files:
wx_config.props - top-level wx settings
wx_setup.props - wx-related macros
wx_local.props - user settings (optional file, not included)

Library was build successfully under VS 2010 and 2012 (and
VisualStudioVersion and PlatformToolset were set properly).

Regards,
AW

[Vadim Zeitlin]

On Tue, 27 May 2014 21:07:53 +0200 Artur Wieczorek wrote:

AW> Attached you can find project files with new naming.
AW> Common configuration files:
AW> wx_config.props - top-level wx settings
AW> wx_setup.props - wx-related macros
AW> wx_local.props - user settings (optional file, not included)
AW>
AW> Library was build successfully under VS 2010 and 2012 (and
AW> VisualStudioVersion and PlatformToolset were set properly).

Thinking more about this, what would happen if VC13 added some new
compiler option, unsupported by VC12 and earlier, we'd like to use? Would
it be possible to somehow still keep using roughly the same files for all
MSBuild-based VC versions and use some macro magic in the .props file to
only use this option for VC13+?

Thanks,
VZ

[David Connet]

Since a prop file can include other prop files (creating a nice inheritance chain), you could create a local prop file for a specific VC version which includes the generic ones. Then compiler specific options could be set there.

Dave

[Michael Richards]

While you guys are in there playing with the files it may be worthwhile to note that for many versions the VS .proj files incorrectly generate the non-DLL build of the libraries as DLL linked libraries. Every new revision of wxWidgets I just go in and fix my local copy anyway, but I've definitely talked to more than one person who has found the same. I think there was a ticket in trac about it somewhere.

-Michael

[Artur Wieczorek]

W dniu 28.05.2014 02:07, David Connet pisze:

> Since a prop file can include other prop files (creating a nice
> inheritance chain), you could create a local prop file for a specific VC
> version which includes the generic ones. Then compiler specific options
> could be set there.
>
> Dave
>
>

> Thinking more about this, what would happen if VC13 added some new
> compiler option, unsupported by VC12 and earlier, we'd like to use?
> Would
> it be possible to somehow still keep using roughly the same files
> for all
> MSBuild-based VC versions and use some macro magic in the .props file to
> only use this option for VC13+?
>

If extra options would be needed for the future versions of VS then
constructs like this could be used (e.g. in 'wx_config.props') to
incorporate special settings:
<Import Project="wx_vc14_config.props"
Condition="'$(VisualStudioVersion)' == '14.0'" />

Regards,
AW

[Artur Wieczorek]

W dniu 28.05.2014 06:49, Michael Richards pisze:

> While you guys are in there playing with the files it may be worthwhile
> to note that for many versions the VS .proj files incorrectly generate
> the non-DLL build of the libraries as DLL linked libraries. Every new
> revision of wxWidgets I just go in and fix my local copy anyway, but
> I've definitely talked to more than one person who has found the same. I
> think there was a ticket in trac about it somewhere.
>
> -Michael
>

Indeed, for external libraries like wxjpeg, wxtiff, wxexpat etc. there
are created static libraries even for DLL configurations.
It seems it is intentional.

Regards,
AW

[Vadim Zeitlin]

On Wed, 28 May 2014 09:50:18 +0200 Artur Wieczorek wrote:

AW> Indeed, for external libraries like wxjpeg, wxtiff, wxexpat etc. there
AW> are created static libraries even for DLL configurations.
AW> It seems it is intentional.

Yes, it is. The versions of these libraries are supposed to be only used
by wxWidgets and so it doesn't make sense to build them as DLLs.

Regards,
VZ

[Michael Richards]

The problem is not the creation of static libs for DLL configs, it is the linkage for static builds. If you specify that you want to build a static library then linking it against a DLL runtime sort of defeats the purpose of a static library since you won't be able to statically link your application anyway. Under code generation in VS I have to go in and change all the runtime linking from DLL to static in order to get it to link. The debug static lib should be built with /MTd and the runtime version should be with /MT. I suspect not many people build static applications so it has never been heavily complained about.

-Michael

[Vadim Zeitlin]

On Wed, 28 May 2014 07:36:24 -0700 (PDT) Michael Richards wrote:

MR> The problem is not the creation of static libs for DLL configs, it is the
MR> linkage for static builds. If you specify that you want to build a static
MR> library then linking it against a DLL runtime sort of defeats the purpose
MR> of a static library since you won't be able to statically link your
MR> application anyway. Under code generation in VS I have to go in and change
MR> all the runtime linking from DLL to static in order to get it to link. The
MR> debug static lib should be built with /MTd and the runtime version should
MR> be with /MT. I suspect not many people build static applications so it has
MR> never been heavily complained about.

All our projects use /MD[d] and this is not planned to change. You can
switch to /MT when using nmake (RUNTIME_LIBS=static) or by changing the
options in the project files as you do, but this is not a bug.

Regards,
VZ

[Vadim Zeitlin]

On Tue, 27 May 2014 21:07:53 +0200 Artur Wieczorek wrote:

AW> Attached you can find project files with new naming.
AW> Common configuration files:
AW> wx_config.props - top-level wx settings

AW> wx_setup.props - wx-related macros

AW> wx_local.props - user settings (optional file, not included)
AW>
AW> Library was build successfully under VS 2010 and 2012 (and
AW> VisualStudioVersion and PlatformToolset were set properly).

Hi,

Sorry for the delay but now that 3.0.1 is almost released, I'd like to
return to this. Unfortunately I already have a first problem: how can I
write wx_local.props now to use the appropriate version-dependent suffix
wxCompilerPrefix, i.e. vc100 or vc110 or vc120?

Sorry for being so helpless with these properties files and TIA!
VZ

[Artur Wieczorek]

> Unfortunately I already have a first problem: how can I
> write wx_local.props now to use the appropriate version-dependent suffix
> wxCompilerPrefix, i.e. vc100 or vc110 or vc120?
>

Hi,
You would need to put following tags in the local configuration file:

<PropertyGroup Label="UserMacros">
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'10.0'">vc100</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'11.0'">vc110</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'12.0'">vc120</wxCompilerPrefix>
</PropertyGroup>

Regards,
AW

[Vadim Zeitlin]

On Sun, 15 Jun 2014 22:39:18 +0200 Artur Wieczorek wrote:

AW> > Unfortunately I already have a first problem: how can I
AW> > write wx_local.props now to use the appropriate version-dependent suffix
AW> > wxCompilerPrefix, i.e. vc100 or vc110 or vc120?
AW>
AW> Hi,
AW> You would need to put following tags in the local configuration file:
AW>
AW> <PropertyGroup Label="UserMacros">
AW> <wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
AW> '10.0'">vc100</wxCompilerPrefix>
AW> <wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
AW> '11.0'">vc110</wxCompilerPrefix>
AW> <wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
AW> '12.0'">vc120</wxCompilerPrefix>
AW> </PropertyGroup>

Unfortunately this doesn't seem to work for me. I have:

% cat build/msw/wx_local.props
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup Label="UserMacros">
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '10.0'">vc100</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '11.0'">vc110</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '12.0'">vc120</wxCompilerPrefix>
</PropertyGroup>

</Project>

But the prefix doesn't seem to be taken into account. If I open the VS
2010 solution, I don't even know how to check its value in the UI but
starting to build it uses "vc_mswud" directory and not "vc100_mswud". And
if I open the 2013 solution, I do see wx_local in the property manager, but
viewing its properties doesn't show anything at all in the "User Macros".
And this even if I remove the conditions.

Any idea about what could I be doing wrong?

Thanks again,
VZ

[Artur Wieczorek]

> But the prefix doesn't seem to be taken into account. If I open the VS
> 2010 solution, I don't even know how to check its value in the UI but
> starting to build it uses "vc_mswud" directory and not "vc100_mswud". And
> if I open the 2013 solution, I do see wx_local in the property manager, but
> viewing its properties doesn't show anything at all in the "User Macros".
> And this even if I remove the conditions.
>

All user macros macros dependent on user-specific wxCompilerPrefix must
be recalculated in wx_local.props so in practice wx_local.props should
be a copy of wx_setup.props with tag
<wxCompilerPrefix>vc</wxCompilerPrefix>
replaced with

<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'10.0'">vc100</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'11.0'">vc110</wxCompilerPrefix>
<wxCompilerPrefix Condition="'$(VisualStudioVersion)' ==
'12.0'">vc120</wxCompilerPrefix>

The simplest way to check the value of any macro is to select 'Edit'
from the drop-down list at e.g. 'Output Directory' item (in any project)
and then click 'Macros >>' button. Somewhere at the bottom of the list
there is a family of $(wx..) macros.

Regards,
AW

[Vadim Zeitlin]

On Tue, 27 May 2014 21:07:53 +0200 Artur Wieczorek wrote:

AW> > I'd probably call the projects just wx_$project.vcxproj though, i.e. avoid
AW> > using "10+" in their names if they are really version independent. But
AW> > other than that this looks good to me. Again, any additional testing and/or
AW> > feedback would be welcome though.
AW>
AW> Attached you can find project files with new naming.

Hi,

I've finally committed them (better late than never), thanks a lot!
VZ

[Artur Wieczorek]

>
> I've finally committed them (better late than never), thanks a lot!
> VZ
>

Hi,

Yes, build\msw folder looks much better now!

It seems that also these files are no longer necessary:
wx_vc10_wx_setup.props
wx_vc11_wx_setup.props
wx_vc12_wx_setup.props
because they are replaced by wx_setup.props.

Regards,
AW

[Vadim Zeitlin]

On Thu, 07 Aug 2014 21:01:34 +0200 Artur Wieczorek wrote:

AW> Yes, build\msw folder looks much better now!
AW>
AW> It seems that also these files are no longer necessary:
AW> wx_vc10_wx_setup.props
AW> wx_vc11_wx_setup.props
AW> wx_vc12_wx_setup.props
AW> because they are replaced by wx_setup.props.

Indeed, thanks for noticing. Removed too now,
VZ