Building (or trying to) GnuCash on Windows

[John Ralls]

> On Nov 30, 2017, at 11:54 AM, Brian Davis <bitminer at gmail.com> wrote:
> 
>> 
>> 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?
> 
> 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?
> 
> 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?
> 
> 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.
> 
> There have been concerns regarding the MS runtime/mingw
> (excetions/crashes/interop problems) and speaks to the very real problem
> that even if you can get it to build it may not be stable (yes one could
> argue the alternative stability of MS run-time in general).
> 
> For instance does: "Program: C:\Program Files
> (x86)\gnucash\bin\gnucash.exe  This application has requested the Runtime
> to terminate it in an unusual way.  Please contact the application's
> support team for more information" sound familiar?  Ironic how this window
> appeared literally while I was writing this... no joke.
> 
> At some point if I recall correctly GTK folks even wanted to build their
> own build tool as apposed to using CMake... I am still waiting for that to
> happen, heck may even help support it as CMake has it's deficiencies some
> through core design and others due to it's evolution.
> 
> 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.
> 
> The page at https://www.gtk.org/download/windows.php https://wiki.gnome.org/
> Projects/GTK+/Win32/MSVCCompilationOfGTKStack still makes me wonder if GTK
> knows what a superbuild is. Then there is Nacho's blog
> https://blogs.gnome.org/nacho/2015/02/19/building-gtk-3-with-msvc-2013/
> which is MSVC 2013 related which is all fine and all until say 2015, 2017
> etc when VS build tools ?evolve?.  I do find it interesting that I have to
> read about how to build a opensource project from someone's dated blog, not
> only that, but if seems the "official"  windows how-to-build link form
> GTK's web site... stellar.  CMake being a metabuild tool can generate vs
> projects for the tools is supports VS/MSbuild, cygwin, MSys/MinGW etc and
> for the various versions 2008, 2010, 2012, 2013, 2015, 2017 etc.
> 
> 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.
> 
> 
> 
> 
>> 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?
> 
> 
> 
>> The scripts for 2.7 and the upcoming 2.8 will help improve the situation.
>> 
> 
> How?
> 
> 
>> 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.  There
> are references to setting up a build server etc.   Where is recipe for this?
> 
> 
>> 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.
> 
> 
> 
>> 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.
> 
> 
>> 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.

That's quite a dump, and since the bulk of it relates to the old build system that will be obsoleted in a few months I'm not going to respond to it except to say that it has been around for something like 15 years and a lot of things have changed in that time. There's no point in putting any effort at all into it considering that we won't be using it after the last 2.6 release a few months from now.

The new scripts are very different indeed. For one thing the bulk of the dependencies are managed by Mingw-w64 rather than built from source. There are trade-offs there but we think that the reduction in time is worthwhile. We do have to build Guile from source because the Mingw-w64 one has Cygwin dependencies that we don't want in Gnucash.exe.

Yes, I briefly considered having CMake do everything instead of writing a Powershell script, but I decided that that it was too much work.

GnuCash did once upon a time build with MSVC, but since then a huge amount of POSIX stuff has crept in. MS has become a lot more POSIX-friendly in the last couple of years and it's possible that GnuCash might be made to build under MSVC. That's not a project that any of the current devs have time for, but you're welcome to take it on if you like. I understand that the Gtk stack has been buildable with MSVC for the last couple of years (Thanks Fan Chun-wei!) but I think that there are other dependencies that are not, principally WebKitGtk, though there may be others.

As for multi-select, multi-select of what and what's the use-case?

Regards,
John Ralls