Building (or trying to) GnuCash on Windows

[Brian Davis]

On Thu, Nov 30, 2017 at 3:46 PM, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> 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.
>
>
ok so then to gnucash-devel list


>
> >
> > 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.
>
>
Ok


> 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.
>
>
So to I start with jhbuild?


> > 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.
>

Yes my point exactly as with GTK.


>
> 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.


At one point I wrote a Windows Script Host to download the particular
version(s) of CMake to boot strap a full system.  Thankfully I came to my
senses and CMake now supports opening VS with environment variables
(environment) set by CMake 3.7+ or so.


> One single click should get the
> curious developer going. Not 20 manual downloads and 30 configuration
> tweaks
> (so to speak).
>

Amen brother.


> > 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.
>
>
Ok


> 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.


If only that were true.  It's one thing to say cross build on Linux, but
WHEN it fails on Windows... How do you go about attaching a debugger?


> 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).
>


Yes the just download a dll or "windows binary" and get started method...
sigh.  But what about tracing bugs into those deps... see this is why I use
cmake to build my deps allowing me source level development of all 3rd
party goop. A glorious option.  Yes with some packages on the web this is
possible.  This does not look like an option with msys/mingw and GTK deps
however.


>
>
> 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).
>
>
So how does one start with 2.8 then?  Say is there a website or something
that explains this?


> > 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.
>

Ok then the download dll or "Windows binaries" approach or more to the
point: download entire build environment and dependencies.



>
> > 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.
>
>
How do I get started there?  Is there some page on the Wiki that explains
this.


> > > 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.
>
>
So it sounds like windows native MSBuild is not an option.


> > > 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.
>

In my experience bugs in deps can be the problem too, but heck at this
point if I could just get it to compile.


>
> 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.
>

So if I understand this if I can get all the deps in binary format I could
possibly build gnucash in VS.    Though I am not sure how to resolve this
with the gcc-isms as mentioned above.


>
> 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.
>

Then I have to wait until the Windows build server creates a version for
testing... if at all.  Curious how long that dev cycle would take.  Then
there is a bug or crash on Windows... then what?


>
> 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).
>

Ok so confused... first use VM then don't use vm, certainly don't use VM to
cross build to windows for testing, just build on Linux and have build
server generate windows version, then don't use linux as no one use it and
build on Windows, don't use the 2.6 scripts, but there is a 2.8 script that
the build server uses and maybe that will work.  Did I about cover that
correctly?


>
> 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.
>
>
Ok so don't build on windows.

Possible compelling reason: Hmm there is a crash.  It happened on
Windows... hey lets compile, hook up a debugger and see why.

I know crazy thought right.

Ya know Java got this wrong with "compile once debug everywhere" right?



> 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.


Windows is what I run GnuCash on and there is where I experience the
crashes.



> 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.
>
>
Right now I would just settle for some way to build a binary version for
Windows that I could attach a debugger to.



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

A way to build a windows binary debug version of GnuCash to which I can
attach a debugger.


>
> 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
>

Maybe this is where I start?

If this is the method for the release of the windows binaries maybe it is
best to start there?  Thoughts on it creating a Windows Debug version.



> 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 am still eager to hear a way to build it.... for debug... on windows.


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


I don't necessarily expect easy at this point... how about possible.


>
> > > 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.
>
>
Yes understood, but the binding to GTK brings with it some build issues.
Also it seems from statements that VS building of GnuCash suffers from
gcc-isms.


> > > 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.
>

Yes understood.  The windows crashes however are windows specific hence the
"other" desire to get it building on Windows.


>
> 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.
>
>
Well I guess I can at least read the code to see how difficult or
impossible it would be to make that change.   User voice feature request go
back to 2011 for which there are multiple feature request for the same
feature.
https://gnucash.uservoice.com/forums/101223-feature-request?query=multi%20select
Not all here are for same feature, but there are at least 3 in the list
that are effectively the same request.