[GNC-dev] Building on Windows

Geert Janssens geert.gnucash at kobaltwit.be
Tue Aug 27 13:19:26 EDT 2019

Op dinsdag 27 augustus 2019 19:00:59 CEST schreef John Ralls:
> > On Aug 27, 2019, at 1:29 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls:
> >>> On Aug 26, 2019, at 1:49 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> >>> wrote:>
> >>> 
> >>> Op zaterdag 24 augustus 2019 19:40:06 CEST schreef Matthew Forbis:
> >>>> I was running gnucash directly from the inst directory and not creating
> >>>> an
> >>>> installer first.  This explanation makes sense.
> >>> 
> >>> There you go.
> >>> 
> >>> It would be nice though to be able to run directly from the inst
> >>> directory
> >>> while debugging as it saves time not having to recreate a bundle for
> >>> each
> >>> iteration.
> >>> 
> >>> Frankly I believe this shows how little actual development really
> >>> happens
> >>> on Windows. Because of that the development experience is not really
> >>> optimized on that platform. With you actively doing so, it may be
> >>> helpful
> >>> to share your experiences so we may make it more attractive for other
> >>> Windows oriented contributors.
> >> 
> >> Has anyone tried Windows Subsystem for Linux
> >> (https://docs.microsoft.com/en-us/windows/wsl/install-win10)? That might
> >> be
> >> a less painful development environment for Windows users at least in the
> >> short term.
> > 
> > I haven't tried it - as far as I know it's not available on Win7.
> > 
> > But as others have already pointed out there are limitations:
> > - from what I have heard it doesn't support GUI applications very well
> > (yet). It is said to be more oriented towards command line utilities.
> > - WSL is a virtual machine, so you'd be running a linux application in a
> > VM, not a native application. Granted, the VM is deeply integrated in
> > Windows so for many users the difference may be hardly noticeable.
> > 
> >> Longer term I think we need to figure out how to make GnuCash buildable
> >> in
> >> Visual Studio. Recent releases provide for a Clang toolchain as well as
> >> the
> >> standard MSVC++ one. We might be able to create a build environment
> >> combined with vcpkg (https://github.com/microsoft/vcpkg) that would be
> >> more
> >> stable, offer a lower barrier to entry, and generate
> >> windows-understandable
> >> debug info.
> > 
> > That would indeed be a more interesting approach. Would that mean we'd
> > have to build the gnucash dependencies in VS as well ? (Aqbanking, guile,
> > webkit,...) Or can VS code link to code built with mingw ? If the latter
> > we could transition in phases: first get GnuCash built and run on VS,
> > while keeping the dependencies as they are, then gradually migrate
> > dependencies (if we want to have the same debug benefits there).
> Win7 goes out of support at the end of the year, meaning only really serious
> security bugs will be fixed (as happened recently with XP). You really
> should upgrade soon.
Will GnuCash stop supporting Win7 as well by that time ? That's my only reason 
to stick to that old platform.

> Let's please be strict about terminology here, it's important: Visual Studio
> (VS) is an IDE like Eclipse. The  Microsoft compiler is Visual C/C++
> (MSVC).
Which I have learned by now from your repeated corrections. Thanks :)
I hope to remember it.

> Yes, MinGW and MSVC libraries with C linkage can be linked at will. MinGW
> links the MS runtime, msvcrt, after all. The issue is C++ libraries using
> C++ linkage. I'm pretty sure that MSVC and gcc use different mangling so
> C++ libraries won't interlink. LLVM [1] mangling depends on what platform
> it's building for, https://clang.llvm.org/docs/MSVCCompatibility.html. That
> probably means that we'll have to build boost before we can build GnuCash.

So we have options it seems.
We could start by figuring out what tweaks would be needed to allow Windows 
devs to use VS with gcc. As our complete Windows build system currently 
depends on gcc, that should be relatively little effort. That still presumes 
we use our own build scripts to set compile all the dependencies, but I hope 
with having done that once and setting a few paths or environment variables in 
a VS project, working on gnucash itself may be reasonably little effort.
>From there we could start to work out if the other dependencies could be 
brought under VS as well or we could release gnucash SDK's, being a pre-
wrapped/pre-built set of dependencies to reduce the getting started overhead.
LLVM or MSVC use can be a separate project.
If a similar thing can be set up as tasks in the VS Code editor, that's yet 
another option.
Now we just need someone to do the experiments. Would have been an interesting 
GSOC project IMO..



More information about the gnucash-devel mailing list