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.gnuc...@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.gnuc...@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.gnuc...@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel