Re: Building (or trying to) GnuCash on Windows

[Brian Davis]

On Thu, Nov 30, 2017 at 3:46 PM, Geert Janssens 
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
> 

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