Building (or trying to) GnuCash on Windows

[Geert Janssens]

It's time to move this thread to the gnucash-devel list. The discussion is 
evolving into the nitty gritty details of how gnucash is built. Not something 
most users will be interested in. If you reply please make sure to do so on 
the devel list.

Op donderdag 30 november 2017 20:54:33 CET schreef Brian Davis:
> > Looking more closely at this, it turned out to be a bug in the boostrap
> > script. I have committed a fix for this just now. So if you start from the
> > most recent version of the script, it should work even when not explicitly
> > called from cscript.
> 
> In looking at the parts that did work it seemed to be installing a msys
> build environment.  There is also some reference to CMake.  Now the
> questions:
> 
> Why not use CMake to do all the heavy lifting?
> 
Because no one implemented it that way, and CMake support is fairly recent in 
the gnucash build scripts.

Besides the new build scripts leverage
1. prebuilt packages from mingw64 - no heavy lifting to be done any more
2.  jhbuild, which is quite capable of managing our dependencies that are not 
provided as prebuilt package by mingw64.

> Scripts also install git... I have git... I also have CMake.... CMake can
> use git command line tools... Why do I need git again?  CMake using
> ExternalProject_Add can add gnucash.git, gnucash-on-windows.git.  Maybe it
> could be changed from download-world-begin-build to
> download-Texas-begin-build?
> 
The goal of the bootstrap script was to lower the barrier to entry as much as 
possible, not to use as little disk space as possible. Before the bootstrap 
script people wanting to try building on Windows had to go through a list of 
packages to install and set up manually, tweaking configuration files in the 
process. This was even more cumbersome and error prone than what this simple 
bootstrap script achieves.

Still in a way I agree with you. The tools that are already available on the 
system shouldn't need to be installed again. Just shows the boostrap process 
can be improved.

But even if you would manage to convert all of this setup stuff into cmake 
rules, I would expect some form of script or "sdk installer" to be available 
that would take care of getting cmake on the system in the first place. The 
core idea of the bootstrap script remains. One single click should get the 
curious developer going. Not 20 manual downloads and 30 configuration tweaks 
(so to speak).

> What are deps on need for MSys/Mingw and could CMake take this over to
> allow VS/MSbuild tools option?  Are there deps such as glib/GTK and other
> dep friends where msbuild tools are not an option?
> 
GnuCash is a glib/Gtk application, so yes those are primary deps. There are 
several others. For the stable series those are listed in defaults.sh, for the 
upcoming 2.8 series you will find them in gnucash.modules.

I don't know whether CMake can take this all over. However the VS/MSbuild 
option doesn't depend on that IMO. The only part you should be concerned about 
is the gnucash code itself. All the deps can be considered as sdk, just set 
and forget. The gnucash code itself is already buildable via cmake, so the VS/
Msbuild option is there to try. I'm pretty sure it will fail though as none of 
the current devs has ever tested it (we don't have any native Windows devs 
atm).

> From my experience attempts to build GTK (and deps) on windows is a flying
> circus, though to be fair "MS sets up the Bigtop" and devs just "fill the
> arena" (apologies to the circus professionals out there in analogy
> comparing them to MS), with build tool access (VS) always having been a
> problem and still is even with the community (tracking/spyware/require
> login/tsunami-wave-of-the-future) editions.

As we are a small core team we prefer to reuse the work of others as much as 
possible. The 2.6 series leveraged the packages of the mingw project (using 
mingw-get) and built those packages that were not available via mingw.

2.8 on the other hand switched to mingw64 and we leverage the packages they 
provide to a maximum to avoid having to rebuild everything ourselves. These 
packages are maintained via https://github.com/Alexpux/MINGW-packages on 
github. Packages not available there we build ourselves. For the 2.8 series 
this is managed via jhbuild. This allows us to reuse much of the work already 
done to build gnucash on OS X (which also uses jhbuild).

> There are GTK deps that do build well (are supported) by CMake such as if i
> remember correctly Zlib, LibPNG, LIbjpeg or Jasper, LibTiff, freetype (has
> CMakeLists.txt file), Expat, pcre2 etc.  Pixman(cairo dep) or dgk-pixbuf
> not so much.  Though I have seen where eventhough there is a CMakeList.txt
> file a project is not fully windows supported (MSBuild tools)  where there
> are deps on build environment Cygwin or MSys.  Sometimes its "hey just
> download this dll"  or "Windows binaries" and go to the next step... kinda
> defeating the purpose.
> 
I don't think we have such instructions in gnucash. We either use the mingw64 
packages (which are rebuildable based on the information in the above 
mentioned github repo) or we build ourselves.

> If mingw is an abs requirement I would be interested to go through this
> script to port functionality to CMake to setup/configure build
> environment.  This would require a 3 stage cmake 1) set up msys build
> environment much as the script does and 2) download  and build dependencies
> in a superbuild 3) build GnuCash.  Possibly combining 2 and 3 into one
> step.  This could remove the gnucash-on-windows.git and git download dep.
> With exsiting MSys install or MSBuild it could possibly be a 1 stage CMake
> superbuild.
> 
Let me be very clear here. You are welcome to suggest improvements to our 
build scripts. If you do however, be sure to base your work on the *NEW* build 
script setup-mingw64.ps1 and related scripts. The 2.6 series is approaching 
end of life and we won't spend any energy trying to overhaul its build 
scripts.

> > P.S.: John's thoughts are worth considering still. Developing gnucash on
> > Windows does add some complexity. And for the 2.6 series it's even
> > cumbersome.
> 
> I think I am on the same page as to the "complexity" (see above).  Is it
> GTK/glib and gtk dep related or does gnucash have similar msys/mingw deps?
> 
Add webkitgtk, guile, and a few others. webkitgtk is the worst. More recent 
versions have become unbuildable on Windows as far as I understand.

In addition one developer has tried in the past to get gnucash to build under 
VS. I don't think the full application was ever built this way, only the non-
gui parts. As our code base is largely written under linux it has several gcc-
isms that are not supported by VS. So making it work under VS is more than 
just getting the build system CMake friendly. It will equally require fixes to 
the code itself.

None of the currently active developers has time for this unfortunately.

> > The scripts for 2.7 and the upcoming 2.8 will help improve the situation.
> 
> How?
> 
Because
1. we depend on mingw64, which has a larger set of prebuilt packages to reuse
2. the other packages are managed by jhbuild, which is a lot smarter and more 
efficient than our old handwritten build scripts.

The new scripts were never written with VS in mind if that is what you 
expected as "improvement".

The idea behind the current build scripts is they set you up some kind of sdk 
for gnucash so you only have to worry about the gnucash code.

The gnucash source itself can be configured with cmake so you can already 
generate VS compatible build scripts now. Feel free to test this and work on 
improving this.

It's not a beginning to end VS thing but after the initial setup in theory you 
could continue to work in VS for most things (barring it was never tested and 
the code probably has many linux-geared quirks VS doesn't understand and hence 
would need fixing first).

> > However depending on your skill and specific goals it's still worth
> > considering to set up a virtual machine running linux instead.
> 
> Yes I can with my VMs build to a remote share for windows testing.

This is not what John and I meant. Our suggestion is you set up a linux 
machine to develop on gnucash and build and run/test the linux version of 
gnucash. Once you are happy with the changes, submit a PR for inclusion and it 
will automatically show up in the next Windows release of gnucash. This 
workflow avoids you from having to use Windows at all.

Using a linux VM to build a Windows version of gnucash is even harder than 
trying to build directly on Windows and even less exercised (as in not at 
all).

What we were trying to convey is that unless you are looking into a very 
Windows specific issue, from our point of view there is no compelling reason 
to build on that platform as things currently stand.

I realize this clearly shows none of the current devs uses Windows as primary 
development platform. And as such we have limited energy and resources 
available to support users that would prefer to do their development there 
anyway. But it looks like you want it to be your platform of choice. I'm fine 
with that although that will mean you'll have to take the situation as it 
currently is. And I hope it can be improved so Windows could equally be a good 
development platform for gnucash. I'm glad our new use of cmake already 
inspires you to bring to devel story on Windows to another level.


> There
> are references to setting up a build server etc.   Where is recipe for this?

What are you looking for exactly ?

Gnucash's windows build server consists of a set of scripts that leverage the 
other build scripts I have already referred to. The core script is build-
server\build-package.ps1
It is designed to set up a machine that will periodically build a gnucash 
installer package, by automatically updating its relevant git repositories and 
then hooking into the other build scripts.

> > More generally though I would also love to see people on Windows pick up
> > gnucash development (on Windows) and in particular help improve the
> > Windows
> > situation where possible.
> 
> Hard to when people can't get it to compile due to build spec and deps.
> 
You're giving up early ;)

I never said it was easy, but it's not even easy on linux due the large amount 
of dependencies.

> > I'm thinking of Windows specific bugs, or
> > improvements to the build system to reduce the complexity gap between
> > developing on Windows and linux. Not sure what could be done for the
> > latter
> > but one can hope, right ;)
> 
> Hmmm CMake build for Linux AND Windows possibly?  If community(frustrated
> devs - read me) could get GTK and their package dep devs to use/support it.
> 
For clarity, we are not affiliated in any way to the Gtk developers. We only 
use their toolkit. So there is not much we can do to improve their Windows 
situation.

> > If this interests you and you think you can, you're certainly welcome to
> > contribute in that area too.
> 
> I wanted to see how hard it would be to implement multi select in GnuCash,
> a feature IMO is long overdue.

This is one example of a platform independent improvement. You can choose any 
development platform to implement this on.

But I  can tell you this will be pretty hard :( The current register code 
predates gtk. So adding multi-select means it has to be written from scratch 
if we want it done in the current code. The alternative would be to replace 
this code with a GtkTreeView, which has a concept of multi select. An effort 
was started in this direction but got stuck on serious performance problems. 
For that reason it was never made the default in 2.6. The new register code is 
still lingering in our source repository and the issues may be fixable. So 
that's an alternative option.

Good luck!

Geert