[GNC-dev] Building on Windows
Dale Phurrough
dale at hidale.com
Wed Aug 28 11:34:41 EDT 2019
With this Windows GnuCash discussion, I see several categories of choices
that seem to be in play for Windows. I'll write here my thoughts and invite
you all to add yet more clarity.
*Library and ABI ecosystem:*
- This is gcc, g++ within msys2 ecosystem while using Linux-esque
libraries. From my rather short time on GnuCash, I think moving away from
the Linux-esque libraries and msys2 ABI to an alternative like the VC++
(Visual C++) ABI/library ecosystem is a *very* large undertaking.
*Compiler:*
- This is closely linked to the choice of the library/ABI ecosystem.
- Currently GnuCash Windows uses gcc, g++ within the msys2 ecosystem.
- gcc/g++ is available on many platforms like Linux, msys2, mingw, etc.
- VC++ compiler is integrated into the Visual Studio IDE -or- can be
downloaded separate as part of Microsoft "build tools".
- VC++ compiler/linker does not compile anything compatible with msys2,
Linux static/dynamic libraries, or ELF executables. The ABIs are
incompatible between gcc and vc++
- Everyone has cmake
*Packager:*
- I list this to invite an exploration into using/making packages for
GnuCash Windows dependencies.
- Visual Studio IDE can use several packaging systems, and they deliver
libraries for appropriate ABI ecosystems
- VS Code can use several packaging systems, and they deliver libraries
for appropriate ABI ecosystems
*Source Code control:*
- I highlight this because of my personal experience with VS Code and
the most recently Visual Studio IDE 2019.
- Both Visual Studio IDE and VS Code support git.
- Visual Studio IDE's support for git technically works, but is
unnatural and difficult for main development workflows. This is due to
legacy pre-git UI workflows and an IDE designed for large teams.
- VS Code's git integration is excellent. And a free extension for VS
Code "git lens" is seamless and goes even further. The combination
surpasses the git capabilities of Visual Studio IDE.
*Editor:*
- Visual Studio IDE can use compilers in Win32 to make a Win32
executable. Two examples are VC++ and gcc-in-msys2
- Visual Studio IDE can use WSL or a remote Linux computer to compile a
Linux ELF executable.
- VS Code can use tools in Windows, WSL, remote computers, Macs, or
Docker containers to compile Windows, Linux ELF, MacOS, Android, ...
- Both editors integrate with C++ debuggers (e.g. gdb and vc++).
- VS Code seems to integrate with a wider set of debuggers beyond those.
- Both editors have intellisense, completion, syntax checking, etc.
- Both editors have extensions to adapt the editor to a developers'
needs. The ecosystem for VS Code is vibrant, good evolution, and free. The
Visual Studio IDE is legacy, conservative, and sometimes fee-based.
- VS Code might support a wider selection of language/debuggers.
- Visual Studio IDE might support a more technical set of debugging
tools (like debugging code running on the GPU) and those tools are
Microsoft-centric.
- Both support cmake in their GUI
- VS Code has a json file you can include with a project that specifies
the extensions needed for the project, possibly allowing for much easier
bootstrapping
https://code.visualstudio.com/docs/editor/extension-gallery#_workspace-recommended-extensions
*Somewhat related examples and one video*
- VS Code compiling with MingW
https://code.visualstudio.com/docs/cpp/config-mingw
- VS Code compiling with VC++
https://code.visualstudio.com/docs/cpp/config-msvc
- Visual Studio IDE compiling with MingW
https://devblogs.microsoft.com/cppblog/using-mingw-and-cygwin-with-visual-cpp-and-open-folder/
- Visual Studio compiling and debugging MingW
https://channel9.msdn.com/Events/Connect/2017/T220
- Visual Studio example settings of what they call "msys2"
https://docs.microsoft.com/en-us/cpp/build/open-folder-projects-cpp?view=vs-2019#example-configuration-for-gcc
--Dale
On Tue, Aug 27, 2019 at 7:20 PM Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:
> 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..
>
> Regards,
>
> Geert
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
More information about the gnucash-devel
mailing list