CMake Build System

[TcT2k]

I would like to know if anybody is currently working on CMake build for wxFormBuilder, which would probably improve Windows and XCode build experience.

There seems to be an existing fork from before the move to github at:
https://github.com/marekr/wxFormBuilder

There has been talk about it at the mailing list:
https://sourceforge.net/p/wxformbuilder/mailman/wxformbuilder-devel/

And it has been mentioned in #246

[patlkli]

Yes, CMake support is done in principle, but I still try to find time to properly test it.

Since the transition to CMake also moves some files around to make the directory structure more reasonable, I can't just push the CMake stuff without breaking Premake on the same branch and I don't want to adjust the old build system for that.

I could push my feature branch without merging it into master if you'd like to help with testing. I certainly would appreciate every help.

It works for me under Ubuntu/Debian with the usual GNU Make generator, but I haven't yet tested the other ones, especially the ones for Windows.

[TcT2k]

I think it would certainly be helpful if you push the feature branch.
I'm not sure how extensively I can test, but I can at least give it a try on Windows and macOS and can create PRs for issues I come across.

[patlkli]

I just pushed the cmake_build branch.

Note: Checking out the respective other branch seems to cause a problem with the submodules, so you might have to run "git submodule update --init" again if you have issues with the submodule.

If you find any issues, you can either post them here in this issue or create a pull request on the cmake_build branch.

[TcT2k]

The issue with the submodule is quite tricky: there is a commit referenced for the submodule:
https://github.com/wxFormBuilder/ticpp/commits/30bf2d3a0f7830a7d77542a2a1cfe0cb9e124055
But this commit is missing from the master branch of ticpp. As a workaround just checking out master works, but you should probably check if the missing commit is important.

I've built xcode and make files on OS X, but have to work out some issues for a successful compile. On Windows (Visual Studio) a few install() calls are missing parameters for windows which blocks project file generation.

I'll look into both platforms and try to at least get them to compile.

[TcT2k]

Building on Windows didn't require many changes, see #265

[patlkli]

I just added Travis build support (#242) in the cmake_build branch, so we now have CI for Windows (MinGW + Visual Studio) and Linux (Ubuntu 14.04 + GCC 4.9).

I saw you started a cmake_build_osx branch in your fork with a Travis config in it, so we'll have to merge that eventually. I can offer to try it out on OSX Sierra 10.12.

[TcT2k]

My osx branch is not worth testing yet. The current cmake_build branch already builds in Xcode (tested with wxWidgets master) but I plan to add proper application bundle building to the cmake files.
I'll merge the travis config when that is done.

[TcT2k]

With PR #266 macOS binaries should now be very usable.

I've not included building OSX on travis yet, as the installation of wxwidgets via brew always hangs.
It would probably be best to build wxWidgets from source in travis before building wxFormBuilder (I think brew builds it from source anyway).

It would probably also be useful upload the created binaries somewhere (e.g. bintray.com).
That would enable easy access to recent macOS builds like with appveyor now.

[jhasse]

It would probably be best to build wxWidgets from source in travis before building wxFormBuilder (I think brew builds it from source anyway).

Fixing the broken brew install would be better IMHO, as other Brew / Travis users would also benefit from that.

[TcT2k]

travis-ci now works, I had installed wxWidgets with --universal which builds 2 sets of binaries (which probably takes to long) and does not use prebuilt binaries.
Default version now installs and wxFormBuilder can be built.

[patlkli]

Appveyor and Travis successfully built the changes in #266, so I merged it just now.

I'm going to try the build manually now and document the build steps in README.md.
If everything is going smooth, I'll merge the cmake_build branch to master tomorrow.

I agree that we should upload the build artifacts from Travis on something like Bintray to provide nightly builds. However I still hope to do the 3.6.1 release soon and distribute that on GitHub.

[jhasse]

Can we do a 3.6.0 release first? This way we should be able to catch any regressions due to the many changes in the cmake_build branch.

[patlkli]

We sure can. We still have a number of issues planned for 3.6.1 anyway, so preceding it with 3.6.0 might be a good idea.

[SpareSimian]

What's necessary when building wxWidgets (from git clone) on Windows to make it work with this? (Since wxWidgets isn't built with CMake, yet. So it lacks any machinery of its own to register its presence or build flags.) What build command should I use? Here's what I currently use for Visual Studio 2015 with my own app and library, as an example (repeated for each compiler I support):

setlocal
call "%vs140comntools%..\..\vc\bin\vcvars32.bat"
nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=dynamic COMPILER_PREFIX=vc14
nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=dynamic COMPILER_PREFIX=vc14
nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=static COMPILER_PREFIX=vc14_static
nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=static COMPILER_PREFIX=vc14_static
endlocal

setlocal
call "%vs140comntools%..\..\vc\vcvarsall.bat" %VSAMD64%
nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=dynamic COMPILER_PREFIX=vc14 TARGET_CPU=x64
nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=dynamic COMPILER_PREFIX=vc14 TARGET_CPU=x64
nmake -f makefile.vc SHARED=0 BUILD=debug RUNTIME_LIBS=static COMPILER_PREFIX=vc14_static TARGET_CPU=x64
nmake -f makefile.vc SHARED=0 BUILD=release RUNTIME_LIBS=static COMPILER_PREFIX=vc14_static TARGET_CPU=x64
endlocal

(VSAMD64 is either x86_amd64 or amd64, depending on whether the building machine is 32 or 64 bit.)

[TcT2k]

You need to build SHARED=1 wxWidgets binaries or use official binaries (which are shared).
You can set the WXWIN environment variable to your wxWidgets folder or you can specify the wxWidgets folder in the cmake gui or via -DwxWidgets_ROOT_DIR=... parameter on the cmake command line.

[jhasse]

We sure can. We still have a number of issues planned for 3.6.1 anyway, so preceding it with 3.6.0 might be a good idea.

Perfect :) I'll update the debian changelog to create a .deb and push a tag tomorrow.

[patlkli]

Perfect :) I'll update the debian changelog to create a .deb and push a tag tomorrow.

Alright, so 3.6.0 will be the last release built with Premake and we'll use CMake starting with 3.6.1.

[jhasse]

I've created a tag and the 3.6.0 release on GitHub. I uploaded the deb package for Ubuntu 16.04 and the installer artifact from AppVeyor by hand.

[patlkli]

@jhasse Perfect, thank you!

@TcT2k
I tried the OS X build on my Sierra machine, but encountered an issue:
I ran my build with this command as usual:
mkdir build_cmake && cd build_cmake && cmake -G XCode .. && cmake --build .
This results in a perfectly fine bundle in build_cmake/src/Debug/wxFormBuilder.app.
However, trying to create a package with any CPack generator, it fails in fixup_bundle for some strange reason while looking for some wxWidgets libraries with very strange version numbers (3.0.0.2.0)

I can't access my Sierra machine right now, but I could provide the exact error message later today.

[TcT2k]

I've tested CPack on macOS with wxWidgets git master (3.1.1) compiled with --cxx11 as shared build and successfully building a ZIP and DMG. Only command line diference to my try was cmake --build . --config Release
But I see no reason why 3.0 shouldn't work. I think the strange version number is actually the name of the .dylib files. Have a look at the otool -l output for the binary.

I might give it a try within travis.

[rjpcomputing]

All,

This is great work, but I have a question... I just am not familiar with the build services and was wondering if a Debian Jessie .deb could be produced as well?

[TcT2k]

I theory all forms of packages should be available via CPack.
Have a look at the different CPack.. Modules here:
https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html

So far I've only tested ZIP, NSIS (exe installer) and WiX (MSI installer) on Windows and DMG, pkg and ZIP on macOS.

There will be some tweaking of the settings required, but it should be possible to build all package types via CPack.

[jhasse]

This is great work, but I have a question... I just am not familiar with the build services and was wondering if a Debian Jessie .deb could be produced as well?

Yes, in .drone.yml change ubuntu:16.04 to debian:jessie and run drone exec (see http://readme.drone.io/0.5/install/cli/). This isn't automated yet and isn't using CMake yet ;)

[patlkli]

Actually, wxFormBuilder got a RFP for the official Debian repository over 10 years ago! (see here)
I think, we should try to get that going again. I guess we won't manage to get it in before freeze for Debian Stretch on 2017-01-05, but maybe we manage to get it into Ubuntu 17.04.

I can take care of that as soon as I'm done with the 3.6.1 release.

[rjpcomputing]

@jhasse

Yes that is what I am looking for.

@patlkli

Yes we got it added. I would suggest getting it all caught up in Debian no matter if we miss the freeze date because it will automatically get into Ubuntu when they pull from Debian Testing.

[jhasse]

I've changed the milestone to 3.7.0 in order to release 3.6.1.

I also cherry-picked 6874054 to master.

I've noticed that the submodule has been renamed on the cmake_build branch, any reason for that?

I think it would be a good idea to get most of this to the master branch and let it co-exist with Premake for a while.

[redtide]

Is there some progress in this? I saw the cmake_build branch and the PR #631, but I was confused about some choices like using CPack, which I don't think we need it at all: Windows has already an InnoSetup script, macOS is something that needs some work that should be handled directly, not from some black box like CMake, which can have its own issues.
So I started my own by converting my original Premake 4 scripts, in order to produce, at least, the same results obtained by running create_build_files4.sh, though IDK if this will be accepted or will end on a wxFB fork (I have lots of improvements in mind that I wasn't able to add at that time because not part of the team).

[jhasse]

I'm sure you can become part of the team :) Not sure who is currently besides @sodevel. I'm no longer working with wxWidgets and also not working on wxFormBuilder.

[redtide]

Thank you, I'm not using wx anymore either but Qt now. I was on the way to create an UI designer for my unrelated project and I'm a bit rusty in that context, so I wanted to try to go back to work on this for some experience, inspiration and freshen up ideas.

[redtide]

It seems I got some working build configuration on Linux, I'm gonna test it with an Archlinux PKGBUILD, then make it work also on VS2019 and MinGW in MSYS2. macOS BigSur will follow, so test also the CI stuff keeping an eye on the work done above.
Meanwhile I tested this work and like mine I haven't got it working with VS2019/MSYS2/MinGW as is. Only using MinGW with some "hack" due a problem with the FindwxWidgets.cmake script module.

[sodevel]

Guess it's only me then who is maintaining the project now. Unfortunately i was very busy with other tasks the last year and i have to catch up on other things first so i can't devote much time to wxFB currently. The reason why i didn't merge the CMake PR's is that i am not familiar with CMake myself but from the small things i know about it, they are not as clean as they could and should be. We have currently 3 build systems in place, my goal is to replace them all with CMake, and that without strange hacks.

Most probably this won't happen in one step so it would be ok for me if CMake would be the 4th build system for some time, but only if it doesn't break the present build systems. Sadly most of the time contributions are just one-hit-wonders, so in the long shot it is up to me to maintain the additions, and right now i can't maintain CMake myself.

[redtide]

Why not let me doing the co-maintainer then? I worked already on this project and I have some experience with some other things other than the CMake build, which it seems to going well here, I got VS2019 and MSYS2 working, I miss some other minor stuff and the macOS build and I'm near to get the same results of my old premake4 scripts.

[redtide]

IMO there are no problems about breaking other build systems, you are not using them together.

You could start by removing my old v4 main scripts, exe and source files or your v5 and use just one. Then when CMake will work, premake can be removed completely.

Not sure about the Meson one, I would keep it as alternative in a scripts directory (see also #672); I don't know much of it but all I heard about it was positive feedback. I use CMake for convenience but I'm not a fan of it, I liked Premake back then but it looks like stalled/unmaintained.

[sodevel]

This is not quite true, currently all these three build systems are indeed required. Premake v4 is required by MacOS because the post-processing scripts require output in certain directories and Premake v5 uses completely different output directories. MSYS2 should work with both Premake versions, but if HiDPI gets enabled in the future for MSVC v5 is required because Manifest processing just doesn't work in v4. On plain Linux both versions should work, but the documentation currently uses the Meson system (i also had in my mind that Flatpak uses Meson but actually it uses Premake v4).

[sodevel]

About your maintainer request, no offense but i don't know you, i won't hand out write access so fast. You have also stated that you are actually not using wxWidgets so i'm not sure about your long term motivation. Although my time is quite limited currently, i am still here and can review and apply PR's in a timely manner, maybe this will work for you in the beginning? This project is still important for the company i work for, i won't disappear easily.

[redtide]

You can ask RJP who I am, I did the v4 scripts, the wxWizard addition, the 2.9/3.0 support, helping to add the wxPHP support and I had already access to svn and ftp at sf.net, at the time I was part of the developer group (irccircle was my username).
I left because I had too much limits and lack of freedom to apply features, if I have to experience that again I prefer to keep a own fork.