Build system(s) for 3.3

[Vadim Zeitlin]

Hello,

One of the first things I'd like to do in master is to finally drop
bakefile 0.x. It has served us well, but its time has passed and by now it
creates more problems than it solves. I don't think anybody is going to
regret it, so this is not about discussing whether we should drop it, but
rather what, if anything, should we replace it with. And this depends on
what kind of make/project files we still want to have.

As we're also going to drop support for pre-MSBuild-based MSVS versions
(i.e. anything < 2010), we don't need makefile.vc any more. And I think we
can afford dropping makefile.gcc as well and tell people to use configure
with MSYS2, which is, AFAICS, the best way of using gcc under MSW nowadays.
So the only remaining kind of makefiles which we may still need is
makefile.unx. I'm not really sure if these makefiles are used much, and
most samples are simple enough to be built using a shell one-liner using
wx-config. But not all of them are. Still, unless someone comes up with a
way to preserve these makefiles, e.g. by (re)generating them with some
other tool, we're probably not going to keep them because I don't want to
maintain them by hand and we're not to preserve bakefile just for them
neither.

I'm, however, willing to maintain MSBuild projects by hand because I
prefer them to the ones generated by CMake that much, so we'll keep those.
I also want to keep autoconf-based Unix build, even if, admittedly, CMake
works quite well there, which means that I'm going to have to change
Makefile.in. One possibility would be to switch to automake, but while
automake on its own is not too bad, it requires using libtool too and I am
still very wary of it, especially under Windows. But OTOH keeping up our
current Makefile.in by hand is not going to be fun at all... If anybody has
any ideas about anything better to do here, it would be great to hear them.

Finally, it would be still as nice as ever to have some way to keep Xcode
projects up to date automatically, but I still don't know of any tool doing
this. Note that I don't think we want to start using some other build
system (meson or whatever) because we already have CMake which is clearly a
de facto standard and I'd just like to have, in addition, a simple way to
build the library (and, ideally, the samples too) for people who don't use
any tools and just want to be able to build it out of the box.

Thanks in advance for your thoughts,
VZ

[Stefan Csomor]

Hi

Finally, it would be still as nice as ever to have some way to keep Xcode
projects up to date automatically, but I still don't know of any tool doing
this. Note that I don't think we want to start using some other build
system (meson or whatever) because we already have CMake which is clearly a
de facto standard and I'd just like to have, in addition, a simple way to
build the library (and, ideally, the samples too) for people who don't use
any tools and just want to be able to build it out of the box.

I had updated my old AppleScript version to a new Python based one (using pbxproj), that creates the Xcode entrires base on the .bkl files. So I'd adapapt this one, if we keep the 'files'-file as base, I'll adapt it to reading this.

Thanks,

Stefan

[Vadim Zeitlin]

Hello again,

I still don't have any good solution for the people using nmake (which is
a surprisingly popular method of building wxMSW, AFAICS, maybe because it's
so simple -- even if it's also so slow) or mingw32-make for building under
Windows. AFAICS we have 4 (!) established build systems that are maintained
semi-manually, which is not ideal, but I think can be managed:

- configure+make where supported (including macOS and MSYS2)
- MSVS solutions for wxMSW
- Xcode projects for wxOSX
- CMake for all of them anywhere -- but at the cost of using CMake

The gaps we (maybe?) need to somehow fill after dropping bakefile are

- MinGW users not using MSYS2, i.e. mingw32-make.
- Building the samples with MSVS and Xcode, as we currently don't provide
the project files for them.
- Building the samples using the already installed library in Unix-like
environments (makefile.unx).


I think we'll have to tell people using nmake to switch to MSBuild
instead, as it's almost as simple and, incidentally, N times faster (where
N is the number of the CPU cores in the system). But what can we do for the
mingw32-make users? I could write a manual GNU makefile for them, but I
can't say I want to do it or maintain it afterwards. Could we just tell
them to use CMake? Does it work well in this environment?

As for the samples, I think for now we'll just have to leave the existing
generated Makefile.in and makefile.unx in the tree. This will definitely
become a maintenance problem later but, well, we'll have to solve it then
because I have no good ideas right now.

Of course, all this comes perilously close to just giving up and accepting
that CMake is the main build system for the project, so I can't help asking
myself if we should just do that... Even if I have to admit that building
using CMake and Ninja under Linux is nice.

Any thoughts/opinions/ideas? I'd like to remove bakefile support
relatively soon.

Thanks,
VZ

[Kenneth Porter]

--On Sunday, July 31, 2022 6:31 PM +0200 Vadim Zeitlin

<va...@wxwidgets.org> wrote:

> I think we'll have to tell people using nmake to switch to MSBuild
> instead, as it's almost as simple and, incidentally, N times faster (where
> N is the number of the CPU cores in the system).

What's involved in switching?

My current batch file has a bunch of command pairs like this, one for each
MSVC version and architecture (32/64). What's the equivalent command for
MSBuild?

nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=dynamic
COMPILER_PREFIX=vc142 TARGET_CPU=x64
nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=dynamic
COMPILER_PREFIX=vc142 TARGET_CPU=x64

[Vadim Zeitlin]

On Sun, 31 Jul 2022 11:07:17 -0700 Kenneth Porter wrote:

KP> --On Sunday, July 31, 2022 6:31 PM +0200 Vadim Zeitlin
KP> <va...@wxwidgets.org> wrote:
KP>
KP> > I think we'll have to tell people using nmake to switch to MSBuild
KP> > instead, as it's almost as simple and, incidentally, N times faster (where
KP> > N is the number of the CPU cores in the system).
KP>
KP> What's involved in switching?

Using msbuild instead of nmake.

KP> My current batch file has a bunch of command pairs like this, one for each
KP> MSVC version and architecture (32/64). What's the equivalent command for
KP> MSBuild?

We'll have to document this, but something along the lines of

msbuild /m /p:Configuration=Debug /p:Platform=x64 build/msw/wx_vcNN.sln

KP> nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=dynamic
KP> COMPILER_PREFIX=vc142 TARGET_CPU=x64
KP> nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=dynamic
KP> COMPILER_PREFIX=vc142 TARGET_CPU=x64

There is no fine control over RUNTIME_LIBS in the MSVS projects, but as
long as you're using the default, you're fine. As for COMPILER_PREFIX, it
can be specified in build/msw/wx_local.props file that you may create (or
by editing wx_setup.props if you don't care about modifying the files under
version control).

Regards,
VZ

[David Connet]

On 7/31/2022 12:16 PM, Vadim Zeitlin wrote:
> There is no fine control over RUNTIME_LIBS in the MSVS projects, but as
> long as you're using the default, you're fine.

Oh bummer. I compile the static libs with /MT...

Maybe this could be setup with a user macro (well, 2  - release/debug)
in wx_setup.props that we could then override in wx_local? (I'm going to
play with that to see...)

Dave

[Vadim Zeitlin]

On Mon, 1 Aug 2022 10:38:40 -0700 David Connet wrote:

DC> On 7/31/2022 12:16 PM, Vadim Zeitlin wrote:
DC> > There is no fine control over RUNTIME_LIBS in the MSVS projects, but as
DC> > long as you're using the default, you're fine.
DC>
DC> Oh bummer. I compile the static libs with /MT...
DC>
DC> Maybe this could be setup with a user macro (well, 2  - release/debug)
DC> in wx_setup.props that we could then override in wx_local? (I'm going to
DC> play with that to see...)

Yes, this should definitely be possible, we just need to use a macro
(wxRuntimeLib?) as <RuntimeLibrary> tag value. If you can add it, test it
to confirm that it works and make a PR adding it, I'd be glad to apply it.

Thanks,
VZ

[Kenneth Porter]

--On Monday, August 01, 2022 11:38 AM -0700 David Connet

<dc...@agilityrecordbook.com> wrote:

> Oh bummer. I compile the static libs with /MT...

I see that I'm using dynamic everywhere, even in VS2013. (Starting with
VS2015, at least the C runtime is now distributed with the OS, so a static
link makes far less sense.) At some point I tested my DLL with a static
runtime due to a customer request to isolate runtime dependencies from
their app (ie. not passing heap pointers across the interface, which means
not using std::string in my interface). So I think I can live with the
default setting. But I appreciate having the choice with the coming option.

[Kenneth Porter]

--On Sunday, July 31, 2022 10:16 PM +0200 Vadim Zeitlin

<va...@wxwidgets.org> wrote:

> As for COMPILER_PREFIX, it can be specified in build/msw/wx_local.props
> file that you may create (or by editing wx_setup.props if you don't care
> about modifying the files under version control).

Editing wx_setup.props works. But my attempt at a wx_local.props doesn't.
The build process is still using "vc" as the prefix. What am I doing wrong
here?

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<_PropertySheetDisplayName>wxWidgets Local Setup
Options</_PropertySheetDisplayName>
</PropertyGroup>
<PropertyGroup Label="UserMacros">
<wxCompilerPrefix>vc14x</wxCompilerPrefix>
</PropertyGroup>
</Project>

[David Connet]

OHOH! I know! You also need to include any variables that are based on
the old ones.

So my wx_local looks like (I don't remember why I set some things, I was
duplicating what my nmake-based script did):

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

  <PropertyGroup Label="UserMacros">
    <wxCompilerPrefix>vc143</wxCompilerPrefix>
    <wxVendor>dconSoft</wxVendor>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros">
<wxOutDirName>$(wxCompilerPrefix)$(wxArchSuffix)_$(wxLibTypeSuffix)$(wxCfg)</wxOutDirName>
    <wxOutDir>..\..\lib\$(wxOutDirName)\</wxOutDir>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros" Condition="'$(Configuration)'=='DLL
Debug'">
<wxIntRootDir>$(wxCompilerPrefix)$(wxArchSuffix)_$(wxToolkitPrefix)$(wxSuffix)dll\</wxIntRootDir>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros" Condition="'$(Configuration)'=='DLL
Release'">
<wxIntRootDir>$(wxCompilerPrefix)$(wxArchSuffix)_$(wxToolkitPrefix)$(wxSuffix)dll\</wxIntRootDir>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros"
Condition="'$(Configuration)'=='Debug'">
<wxIntRootDir>$(wxCompilerPrefix)$(wxArchSuffix)_$(wxToolkitPrefix)$(wxSuffix)\</wxIntRootDir>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros"
Condition="'$(Configuration)'=='Release'">
<wxIntRootDir>$(wxCompilerPrefix)$(wxArchSuffix)_$(wxToolkitPrefix)$(wxSuffix)\</wxIntRootDir>
  </PropertyGroup>
  <PropertyGroup Label="UserMacros">
<wxToolkitDllNameSuffix>_$(wxCompilerPrefix)$(wxArchSuffix)_$(wxVendor)</wxToolkitDllNameSuffix>
  </PropertyGroup>
  <ItemDefinitionGroup>
    <ClCompile>
<PreprocessorDefinitions>wxMSVC_VERSION_AUTO=1;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <AdditionalOptions>/Zc:__cplusplus
%(AdditionalOptions)</AdditionalOptions>
      <LanguageStandard>stdcpp17</LanguageStandard>
    </ClCompile>
  </ItemDefinitionGroup>
</Project>

Dave

[Kenneth Porter]

On 8/2/2022 6:13 AM, David Connet wrote:
> OHOH! I know! You also need to include any variables that are based on
> the old ones.

Aha, that makes sense. I guess the XML macros are expanded top-to-bottom
just like with the C preprocessor, so I need to re-introduce all the
macros defined in wx_setup.props that depend on my changes. Thanks!

[David Connet]

I discovered that the hard way too... Took a few false starts until I
figured that out...

Dave

[Kenneth Porter]

I should write a script to write wx_local.props, since so much is
boilerplate or computed from wx_setup.props. I can then call that from
my build script that builds wx for all the different compiler
versions/architectures and debug/release.

[David Connet]

I have one... Once my PR goes in, I'll push to my project.

If you're interested, it's the "CompileWX.py" script in
https://github.com/dconnet/AgilityBook/tree/master/build. (It also makes
use of stuff in the pyDcon folder)

Dave

[David Connet]

FYI: I've pushed these changes, so if you're interested in my python
script, it now supports building WX (just trunk) via msbuild.

Dave

[Kenneth Porter]

On 8/4/2022 7:02 AM, David Connet wrote:

If you're interested, it's the "CompileWX.py" script in https://github.com/dconnet/AgilityBook/tree/master/build. (It also makes use of stuff in the pyDcon folder)

FYI: I've pushed these changes, so if you're interested in my python script, it now supports building WX (just trunk) via msbuild.

Thanks! I added a watch to your project and I'll integrate the scripts into my own build instructions.

[Vadim Zeitlin]

Hello again,

I'm still looking at the build system to use for wx 3.3 and I'm curious if
anybody here has tried xmake (https://xmake.io/)? It looks like it could be
convinced to generate everything we need using its "project" plugin which
is, of course, similar to the current situation with bakefile but it could
also be used to build things directly for people who'd be ready to install
it and its syntax is much nicer than bakefile 0.x (and while I still prefer
the declarative syntax of bakefile 1.x, xmake has the advantage of being
written by other people and wouldn't need to be maintained by ourselves).
Also, even though I'm not very comfortable with Lua personally, it's not a
difficult language to use/learn and I hope using it wouldn't be as big a
barrier to the entry as bakefile is.

Please let me know if you have any arguments for and, especially, against
using xmake, before I waste any time on doing something that has no chance
of working (for any reason I don't see yet).

Thanks!
VZ

[wsu]

I had never even heard of xmake before your msg, so I don't know enough to actually be against it.  On the other hand, as a full-time professional software developer for over 25 years, that's suggests it's at least somewhat obscure.

I do see at least one disadvantage to xmake: it looks like it's not registered at https://layers.openembedded.org/layerindex/branch/master/recipes/?q=xmake, which suggests that it is not supported by the Yocto project.  (Yocto does support wxwidgets 3.1.5.)  On the other hand, do I understand your message to imply xmake can generate Makefile's that we could commit to the git repository to allow building using GNU make without builders actually needing to have xmake?  That would suffice to enable Yocto to build wxwidgets even if it doesn't support xmake.

[Vadim Zeitlin]

On Sun, 28 Aug 2022 17:44:28 -0700 (PDT) wsu wrote:

w> I had never even heard of xmake before your msg, so I don't know enough to
w> actually be against it. On the other hand, as a full-time professional
w> software developer for over 25 years, that's suggests it's at least
w> somewhat obscure.

It's new and definitely not without problems (e.g. documentation is not
great and naming is downright weird), but we need _something_ to replace
bakefile-0.x and so far I don't have anything at all.

w> I do see at least one disadvantage to xmake: it looks like it's not
w> registered at
w> https://layers.openembedded.org/layerindex/branch/master/recipes/?q=xmake,
w> which suggests that it is not supported by the Yocto project. (Yocto does
w> support wxwidgets 3.1.5.) On the other hand, do I understand your message
w> to imply xmake can generate Makefile's that we could commit to the git
w> repository to allow building using GNU make without builders actually
w> needing to have xmake? That would suffice to enable Yocto to build
w> wxwidgets even if it doesn't support xmake.

Yes, I hope we could use it to generate .vcxproj and makefiles for the
samples.

Regards,
VZ

[Vadim Zeitlin]

Hello,

I'm still trying to find some way to generate the project/make files for
the samples for 3.3.0 release and I've decided to take another look at
premake. My first impression is rather positive: this simple premake5.lua
file

---------------------------------- >8 --------------------------------------
workspace "minimal"
configurations { "Debug", "Release" }

project "minimal"
kind "WindowedApp"
language "C++"

includedirs { "../../include/msvc", "../../include" }
libdirs { "../../lib/vc14x_lib" }

defines { "wxMSVC_VERSION_ABI_COMPAT" }
defines { "UNICODE", "_UNICODE" }

files { "*.cpp", "../sample.rc" }

filter "configurations:Debug"
defines { "DEBUG" }
symbols "On"

filter "configurations:Release"
defines { "NDEBUG" }
optimize "On"
---------------------------------- >8 --------------------------------------

produces working MSVS 201x solution/project files.

However there are, of course, many things I'd like to change/improve:

1. I'd like to use a Premake module ("wxsample"?) to define most of the
options above only once instead of repeating them for all samples.
This seems doable, although I haven't actually tried doing it yet.

2. I'd like to customize the generated solution file to include
dependencies on the wx libraries used by the sample. I haven't seen
a way to do this yet.

3. I'd really like to remove PlatformToolset from the generated .vcxproj
files and include build/msw/wx_config.props instead, so that the same
.vcxproj file could be used by all MSVS versions instead of having to
have half a dozen of almost identical project files.

I'm going to try to have a look at these points myself, but if somebody
with Premake experience (of which I have none at all) or better knowledge
of Lua (of which I have very little) could help with doing this, I'd be
grateful.

Thanks in advance for any help or hints!
VZ