Re: [GNC-dev] Building on Windows
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 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.
Re: [GNC-dev] Building on Windows
Op dinsdag 27 augustus 2019 19:00:59 CEST schreef John Ralls: > > On Aug 27, 2019, at 1:29 AM, Geert Janssens > > wrote:> > > Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls: > >>> On Aug 26, 2019, at 1:49 AM, Geert Janssens > >>> 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
Re: [GNC-dev] Building on Windows
> On Aug 27, 2019, at 1:29 AM, Geert Janssens > wrote: > > Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls: >>> On Aug 26, 2019, at 1:49 AM, Geert Janssens >>> 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. 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). 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. Regards, John Ralls [1] VS 2019 can build CMake projects using Clang: https://devblogs.microsoft.com/cppblog/clang-llvm-support-in-visual-studio/ and that might mangle the sa ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
> On Aug 27, 2019 w35d239, at 11:01 AM, John Ralls wrote: > > > VSCode can't build anything, it's just an editor. But it can call[1] out to > the build system to do whatever build for whatever platform you like. Visual > Studio is the full-featured IDE and there's a free (as in beer, Microsoft > hasn't gotten *that* far down the open source road!) version [2]. There's > even a Mac version[3] that's probably better than Xcode, though admittedly > that's not saying much. And probably why it is seemingly used primarily for web based development so far. > > I don't know much about WSL, I was wondering out loud. WSL was not-so-allegedly created so devs can stick with the MS desktop and develop for Linux on it. (primarily) It runs (as of v2) a real Linux kernel in a Win10 managed ‘utility’ VM with very little overhead or performance hit. The code executed is ‘Linux’ code. Some potential uses are to run Linux apps ‘on’ Windows desktops with a native feel and performance. (supposedly WSL2 will achieve that) It stems some bleeding of devs away from the MS platform, but also makes it easier for MS devs to work on the Linux kernel which they have started contributing to. (probably for WSL, a bit circular) Note, that sentence is pure conjecture from the interwebs. There is some evidence for this with the new VSCode Remote which is an extension where you run VSCode on windows, but ‘remote into’ WSL: https://code.visualstudio.com/docs/remote/wsl (making it easy to stick with Windows, but still develop for Linux) Regards, Adrien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
My understanding, and the link you posted does nothing to gainsay it, is that
VSCode is an editor like emacs. You need other tools to do the building,
packaging, and debugging. Like emacs, those tools can be integrated with the
editor via tasks (link in previous email).
What's your full setup for development using VSCode? How much effort is needed
to duplicate it?
Regards,
John Ralls
> On Aug 27, 2019, at 5:37 AM, Dale Phurrough via gnucash-devel
> wrote:
>
> I noticed earlier the use of "VS" and was watching it for context. Now I
> see more clearly what was intended.
> You want to actually use the Visual Studio UI and the Visual Studio
> compiler. And consider VS Code a lesser option "at a stretch".
>
> I've tons of experience with Visual Studio. It is good for legacy Visual
> Studio projects, large in-house teams, and rigid development cycles. None
> of those three align well with GnuCash.
> Contrast that to VS Code. Personally, I use it for everything now. And I
> use it across platforms, across projects, and always with open-source
> projects.
>
> This "windows developer" that you are seeking...are you sure they want
> Visual Studio? Or is VS Code a better fit? I ask because the approach one
> takes will be different between the two; and likely not worth the effort to
> support both.
> Each of the two will have their own possibilities of: editor, packager, and
> compiler/linker. Luckily, there is some overlap.
> Here is recently statistics and reports on dev tool use VS Code and Visual
> Studio. VS Code is ahead and the younger devs (via hires) prefer it.
> https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx
>
>
>
> On Tue, Aug 27, 2019 at 1:52 PM Geert Janssens
> wrote:
>
>> Thanks for the suggestion. However the goal is not only to get a linux
>> GnuCash
>> running on Windows. We already do better than that so it would be a step
>> back
>> to what we do now.
>> The goal is to make it easy to develop GnuCash *natively* on Windows ("as
>> easy
>> as on linux") to make it more attractive for native Windows developers to
>> join
>> the effort. Having a native Windows developer go through the hoops of
>> MingW/
>> MSYS or even docker with linux is to high a barrier. Those are not the
>> tools
>> of choice for a Windows developer. Visual Studio is the environment of
>> choice,
>> or the lighter VS Code at a stretch. Want Windows developers to be
>> interested
>> ? Make sure they can continue to use their tools.
>>
>> Regards,
>>
>> Geert
>>
>> Op dinsdag 27 augustus 2019 12:58:47 CEST schreef Dale Phurrough via
>> gnucash-
>> devel:
>>> If your goal is to use a Windows computer to run and/or develop GnuCash,
>>> then an option is to...
>>> Execute GnuCash in Linux
>>> Display GnuCash in Windows
>>>
>>> I do not recommend deep investment into the current WSL. The drastically
>>> different WSL2 is already in preview and will be available within ~6-9
>>> months. At that point, there will be a full Linux kernel available. If it
>>> works in WSL1, it will probably work in WSL2...but you will likely have
>>> many workarounds/hacks that will be obsolete.
>>> Do Linux work in a Docker container. Host that container either on
>> Windows
>>> or on any Linux machine you have that can run Docker.
>>> Use X Windows to remote the GnuCash display from the Docker container to
>>> your Windows machine. This is standard XWindows remoting.
>>> Now you have GnuCash GUI being displayed on a Windows machine, GnuCash
>>> executable running in the Docker container wherever it is, and the X
>>> Windows protocol connecting the two together.
>>> I do this often, across many Linux OS, all remoted to my same Windows 10
>>> computer.
>>> And yes, you can run the Docker container on same same Windows computer
>>> showing the GUI.
>>>
>>> 1. Get a working Docker install. This is easy. Available for Windows and
>>> every Linux distribution https://docs.docker.com/install/
>>> 2. Get a working XWindows install for Windows. I use cygwin's XWin
>> because
>>> setup was easy and it is free. https://x.cygwin.com/
>>> 3. Get a working GnuCash Docker container. This is easy
>>> https://github.com/diablodale/gnucash-dev-docker
>>>
>>> --Dale
>>>
>>> On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone <
>>>
>>> adrien.montele...@lusfiber.net> wrote:
> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj <
bhardw...@outlook.com> wrote:
> WSL would provide a Linux binary, not a Windows binary. Is that what
>> you
are thinking of building? I am also not sure how to get GUI running for
WSL. (WSL is really good tool.)
That’s what I was thinking too, but maybe John knows something we
>> don’t.
If the goal of being able to build via VSCode is reached, then you can
>> use
one machine and do both builds, one for Linux, the other for Windows.
>> I’ve
not heard that the Linux version of VSCode can build a Windows binary.
(would be great if it
Re: [GNC-dev] Building on Windows
Interesting. Also very interesting, is this graph form the survey showing how the technologies relate to each other, and from that one *might* surmise the use cases: https://insights.stackoverflow.com/survey/2018#correlated-technologies If I’m reading that correctly, it looks like VSCode is the preferred IDE for JS/TS developers for web applications. Devs working more directly on Windows Desktop seem to prefer the full VS, but that might also be affected by the demographics - younger developers are preferring VSCode and they are gravitating towards web platforms rather than desktop. > On Aug 27, 2019 w35d239, at 7:37 AM, Dale Phurrough wrote: > > I noticed earlier the use of "VS" and was watching it for context. Now I see > more clearly what was intended. > You want to actually use the Visual Studio UI and the Visual Studio compiler. > And consider VS Code a lesser option "at a stretch". > > I've tons of experience with Visual Studio. It is good for legacy Visual > Studio projects, large in-house teams, and rigid development cycles. None of > those three align well with GnuCash. > Contrast that to VS Code. Personally, I use it for everything now. And I use > it across platforms, across projects, and always with open-source projects. > > This "windows developer" that you are seeking...are you sure they want Visual > Studio? Or is VS Code a better fit? I ask because the approach one takes will > be different between the two; and likely not worth the effort to support both. > Each of the two will have their own possibilities of: editor, packager, and > compiler/linker. Luckily, there is some overlap. > Here is recently statistics and reports on dev tool use VS Code and Visual > Studio. VS Code is ahead and the younger devs (via hires) prefer it. > https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
> On Aug 26, 2019, at 10:15 PM, Adrien Monteleone > wrote: > > >> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj >> wrote: >> >> WSL would provide a Linux binary, not a Windows binary. Is that what you are >> thinking of building? I am also not sure how to get GUI running for WSL. >> (WSL is really good tool.) > > That’s what I was thinking too, but maybe John knows something we don’t. If > the goal of being able to build via VSCode is reached, then you can use one > machine and do both builds, one for Linux, the other for Windows. I’ve not > heard that the Linux version of VSCode can build a Windows binary. (would be > great if it could) > > As for the GUI, some people have done it, though MS doesn’t support it. (even > running GnuCash!) But I haven’t tried it myself. I’m just getting ready to > play with Win10 for a client (I don’t use Win systems regularly anymore) so I > might give it a go in a month or so. VSCode can't build anything, it's just an editor. But it can call[1] out to the build system to do whatever build for whatever platform you like. Visual Studio is the full-featured IDE and there's a free (as in beer, Microsoft hasn't gotten *that* far down the open source road!) version [2]. There's even a Mac version[3] that's probably better than Xcode, though admittedly that's not saying much. I don't know much about WSL, I was wondering out loud. Regards, John Ralls [1] https://code.visualstudio.com/docs/editor/tasks [2] https://visualstudio.microsoft.com/downloads/ [3] https://visualstudio.microsoft.com/vs/mac/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Op dinsdag 27 augustus 2019 14:37:21 CEST schreef Dale Phurrough: > I noticed earlier the use of "VS" and was watching it for context. Now I > see more clearly what was intended. > You want to actually use the Visual Studio UI and the Visual Studio > compiler. And consider VS Code a lesser option "at a stretch". > > I've tons of experience with Visual Studio. It is good for legacy Visual > Studio projects, large in-house teams, and rigid development cycles. None > of those three align well with GnuCash. > Contrast that to VS Code. Personally, I use it for everything now. And I > use it across platforms, across projects, and always with open-source > projects. > > This "windows developer" that you are seeking...are you sure they want > Visual Studio? Or is VS Code a better fit? I ask because the approach one > takes will be different between the two; and likely not worth the effort to > support both. > Each of the two will have their own possibilities of: editor, packager, and > compiler/linker. Luckily, there is some overlap. > Here is recently statistics and reports on dev tool use VS Code and Visual > Studio. VS Code is ahead and the younger devs (via hires) prefer it. > https://visualstudiomagazine.com/blogs/data-driver/2018/12/2018-vs-code.aspx Well, this shows I'm not a Windows developer myself. The way I was told Visual Studio was the full product and VS Code a lightweight open sourced edition. That may be totally off. So based on your feedback VS Code support is what we should focus on. From what I understand that's a cross-platform IDE so we could even experiment with it on linux. Though the same applies in the other direction of course: linux users have *their* preferred tools and habits :) Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
If your goal is to use a Windows computer to run and/or develop GnuCash, then an option is to... Execute GnuCash in Linux Display GnuCash in Windows I do not recommend deep investment into the current WSL. The drastically different WSL2 is already in preview and will be available within ~6-9 months. At that point, there will be a full Linux kernel available. If it works in WSL1, it will probably work in WSL2...but you will likely have many workarounds/hacks that will be obsolete. Do Linux work in a Docker container. Host that container either on Windows or on any Linux machine you have that can run Docker. Use X Windows to remote the GnuCash display from the Docker container to your Windows machine. This is standard XWindows remoting. Now you have GnuCash GUI being displayed on a Windows machine, GnuCash executable running in the Docker container wherever it is, and the X Windows protocol connecting the two together. I do this often, across many Linux OS, all remoted to my same Windows 10 computer. And yes, you can run the Docker container on same same Windows computer showing the GUI. 1. Get a working Docker install. This is easy. Available for Windows and every Linux distribution https://docs.docker.com/install/ 2. Get a working XWindows install for Windows. I use cygwin's XWin because setup was easy and it is free. https://x.cygwin.com/ 3. Get a working GnuCash Docker container. This is easy https://github.com/diablodale/gnucash-dev-docker --Dale On Tue, Aug 27, 2019 at 7:15 AM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > > > On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj < > bhardw...@outlook.com> wrote: > > > > WSL would provide a Linux binary, not a Windows binary. Is that what you > are thinking of building? I am also not sure how to get GUI running for > WSL. (WSL is really good tool.) > > That’s what I was thinking too, but maybe John knows something we don’t. > If the goal of being able to build via VSCode is reached, then you can use > one machine and do both builds, one for Linux, the other for Windows. I’ve > not heard that the Linux version of VSCode can build a Windows binary. > (would be great if it could) > > As for the GUI, some people have done it, though MS doesn’t support it. > (even running GnuCash!) But I haven’t tried it myself. I’m just getting > ready to play with Win10 for a client (I don’t use Win systems regularly > anymore) so I might give it a go in a month or so. > > Regards, > Adrien > > > ___ > 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
Re: [GNC-dev] Building on Windows
Op maandag 26 augustus 2019 18:32:40 CEST schreef John Ralls: > > On Aug 26, 2019, at 1:49 AM, Geert Janssens > > 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). Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
> On Aug 26, 2019 w35d238, at 11:28 PM, Sumit Bhardwaj > wrote: > > WSL would provide a Linux binary, not a Windows binary. Is that what you are > thinking of building? I am also not sure how to get GUI running for WSL. (WSL > is really good tool.) That’s what I was thinking too, but maybe John knows something we don’t. If the goal of being able to build via VSCode is reached, then you can use one machine and do both builds, one for Linux, the other for Windows. I’ve not heard that the Linux version of VSCode can build a Windows binary. (would be great if it could) As for the GUI, some people have done it, though MS doesn’t support it. (even running GnuCash!) But I haven’t tried it myself. I’m just getting ready to play with Win10 for a client (I don’t use Win systems regularly anymore) so I might give it a go in a month or so. Regards, Adrien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
WSL would provide a Linux binary, not a Windows binary. Is that what you are thinking of building? I am also not sure how to get GUI running for WSL. (WSL is really good tool.) MSVC clang support is improving fast. When I downloaded GnuCash source code, the challenge was missing dependencies. I haven't tried it after that, but I can try and report back. -Sumit -Original Message- From: gnucash-devel On Behalf Of John Ralls Sent: Monday, August 26, 2019 09:33 To: Geert Janssens Cc: gnucash-devel@gnucash.org; Matthew Forbis Subject: Re: [GNC-dev] Building on Windows > On Aug 26, 2019, at 1:49 AM, Geert Janssens > 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fwsl%2Finstall-win10data=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=TSQl1pt%2B1XoY%2BP7MU%2BDFoneh4xUiiHZjypyf6YPJw%2Bk%3Dreserved=0)? That might be a less painful development environment for Windows users at least in the short term. 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvcpkgdata=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=jnvhX6%2FizBe%2Fn5ERFcKGvs6WSjT1oZushJ%2BhHwhlQZY%3Dreserved=0) that would be more stable, offer a lower barrier to entry, and generate windows-understandable debug info. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-develdata=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942sdata=VYw%2BkXmJkGDKza2sikiz7aLNctqrpbdT119bqc2ndI4%3Dreserved=0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
> On Aug 26, 2019, at 1:49 AM, Geert Janssens > 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. 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. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
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. This issue is a good example. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Op zaterdag 24 augustus 2019 18:22:42 CEST schreef John Ralls: > > On Aug 23, 2019, at 11:28 PM, Geert Janssens > > wrote: > > > > Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via > > gnucash-> > > devel: > >> I have finally had time to sit down and try again. When libxml > >> development > >> was installed via pacman, it installed icu64 in addition to the icu61 > >> that > >> was already installed by the gnucash script. I was able to remove icu64 > >> and clear out the entire build and inst directories and try again. It > >> built without errors at that point and then the first time I ran, it > >> crashed. I had to do a glib-compile-schemas in order for it to run at > >> that > >> point. (I'm just documenting manual interactions in case the scripts > >> should be updated some for others). > >> > >> Thanks all for your help so far. Now onto trying to debug the chart hang > >> problem. > > > > Thanks for the feedback. > > > > How exactly did you run gnucash ? > > > > I think the whole windows build system is set up to create a Windows > > installer for the gnucash package and run gnucash after this installer > > has run. > > > > On the other hand, if simply running the glib-compile-schemas on the end > > result of the build script helps you run it without invoking the Windows > > installer, that's a worthwile bonus. > > > > I *thought* we did run this while building, but a quick scan of the build > > scripts suggest it's only run while bundling gnucash. I wonder why that > > is. > > Perhaps John remembers. > > Because everything else that uses GSettings is built by MinGW, because > there's no need for GSettings during the build process and > glib-compile-schemas is comprehensive so running it once at the end does > the job. > I may not have been very clear. I do understand all that. However I was thinking of the ability to run from the build directory while debugging. From what I understand that requires glib-compile-schemas to run once at the end of the build process. > IIRC we disabled compiling the schemas at build time because it set up the > paths for the build directory and so the compiled schemas failed after the > install step. > I had to refresh my memory and dug a bit through the various code bits. IUIC the issue may be slightly more nuanced. >From what I understand the gschemas.compile file only holds information on the schema files it finds during compilation (obviously). During build the compile step will only find the gnucash gschema files. However as gnucash relies on gtk as well, it also needs the gtk gschema files at run time. So if we want to run gnucash directly from the build directory [1], gnucash needs to find those files as well. As long as gnucash is run from a mingw32 shell, they should be found as in that environment the gtk gschemas will be installed in mingw's default system location, and ours are installed in the build dir. The same should be valid for running directly from the install location (the one where 'make install' puts the files). However when bundling everything in the installer, suddenly the gtk and gnucash gschemas end up in the same directory, and both gtk and gnucash have a gschemas.compiled file available for bundling. And those files a. only cover their respective gschema files b. want to be installed in the same location with the same name So for the installer a new one has to be generated that covers all gschema files that are part of the bundle. To be fair I'm not sure the gschema compilation would be the only missing piece to allow running directly from build or inst. I do think on the other hand this particular issue may be solvable fairly easily. (I have fired up my Windows build to experiment with this). > As for the build system set up, build_package.ps1 does indeed build a > setup.exe for distribution and even uploads it to the distribution server > if provided with an upload URI. For other purposes the build system does > require a bit of manual intervention. That's equally true on Unix including > MacOS. As far as I know nothing has to be done in particular on linux. I can run cmake with a custom install path, build/install and then run gnucash from where it got installed. I'm probably so used to it I forgot that's not the case on the other platforms. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
I was running gnucash directly from the inst directory and not creating an installer first. This explanation makes sense. Thanks,Matt On Saturday, August 24, 2019, 11:22:48 AM CDT, John Ralls wrote: > On Aug 23, 2019, at 11:28 PM, Geert Janssens > wrote: > > Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash- > devel: >> I have finally had time to sit down and try again. When libxml development >> was installed via pacman, it installed icu64 in addition to the icu61 that >> was already installed by the gnucash script. I was able to remove icu64 >> and clear out the entire build and inst directories and try again. It >> built without errors at that point and then the first time I ran, it >> crashed. I had to do a glib-compile-schemas in order for it to run at that >> point. (I'm just documenting manual interactions in case the scripts >> should be updated some for others). >> >> Thanks all for your help so far. Now onto trying to debug the chart hang >> problem. >> > Thanks for the feedback. > > How exactly did you run gnucash ? > > I think the whole windows build system is set up to create a Windows > installer > for the gnucash package and run gnucash after this installer has run. > > On the other hand, if simply running the glib-compile-schemas on the end > result of the build script helps you run it without invoking the Windows > installer, that's a worthwile bonus. > > I *thought* we did run this while building, but a quick scan of the build > scripts suggest it's only run while bundling gnucash. I wonder why that is. > Perhaps John remembers. Because everything else that uses GSettings is built by MinGW, because there's no need for GSettings during the build process and glib-compile-schemas is comprehensive so running it once at the end does the job. IIRC we disabled compiling the schemas at build time because it set up the paths for the build directory and so the compiled schemas failed after the install step. As for the build system set up, build_package.ps1 does indeed build a setup.exe for distribution and even uploads it to the distribution server if provided with an upload URI. For other purposes the build system does require a bit of manual intervention. That's equally true on Unix including MacOS. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
> On Aug 23, 2019, at 11:28 PM, Geert Janssens > wrote: > > Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash- > devel: >> I have finally had time to sit down and try again. When libxml development >> was installed via pacman, it installed icu64 in addition to the icu61 that >> was already installed by the gnucash script. I was able to remove icu64 >> and clear out the entire build and inst directories and try again. It >> built without errors at that point and then the first time I ran, it >> crashed. I had to do a glib-compile-schemas in order for it to run at that >> point. (I'm just documenting manual interactions in case the scripts >> should be updated some for others). >> >> Thanks all for your help so far. Now onto trying to debug the chart hang >> problem. >> > Thanks for the feedback. > > How exactly did you run gnucash ? > > I think the whole windows build system is set up to create a Windows > installer > for the gnucash package and run gnucash after this installer has run. > > On the other hand, if simply running the glib-compile-schemas on the end > result of the build script helps you run it without invoking the Windows > installer, that's a worthwile bonus. > > I *thought* we did run this while building, but a quick scan of the build > scripts suggest it's only run while bundling gnucash. I wonder why that is. > Perhaps John remembers. Because everything else that uses GSettings is built by MinGW, because there's no need for GSettings during the build process and glib-compile-schemas is comprehensive so running it once at the end does the job. IIRC we disabled compiling the schemas at build time because it set up the paths for the build directory and so the compiled schemas failed after the install step. As for the build system set up, build_package.ps1 does indeed build a setup.exe for distribution and even uploads it to the distribution server if provided with an upload URI. For other purposes the build system does require a bit of manual intervention. That's equally true on Unix including MacOS. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Op vrijdag 23 augustus 2019 22:49:12 CEST schreef Matthew Forbis via gnucash- devel: > I have finally had time to sit down and try again. When libxml development > was installed via pacman, it installed icu64 in addition to the icu61 that > was already installed by the gnucash script. I was able to remove icu64 > and clear out the entire build and inst directories and try again. It > built without errors at that point and then the first time I ran, it > crashed. I had to do a glib-compile-schemas in order for it to run at that > point. (I'm just documenting manual interactions in case the scripts > should be updated some for others). > > Thanks all for your help so far. Now onto trying to debug the chart hang > problem. > Thanks for the feedback. How exactly did you run gnucash ? I think the whole windows build system is set up to create a Windows installer for the gnucash package and run gnucash after this installer has run. On the other hand, if simply running the glib-compile-schemas on the end result of the build script helps you run it without invoking the Windows installer, that's a worthwile bonus. I *thought* we did run this while building, but a quick scan of the build scripts suggest it's only run while bundling gnucash. I wonder why that is. Perhaps John remembers. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
I have finally had time to sit down and try again. When libxml development was installed via pacman, it installed icu64 in addition to the icu61 that was already installed by the gnucash script. I was able to remove icu64 and clear out the entire build and inst directories and try again. It built without errors at that point and then the first time I ran, it crashed. I had to do a glib-compile-schemas in order for it to run at that point. (I'm just documenting manual interactions in case the scripts should be updated some for others). Thanks all for your help so far. Now onto trying to debug the chart hang problem. Thanks, Matt On Friday, August 16, 2019, 7:53:09 AM CDT, Matthew Forbis wrote: Yes I have that commit on my system and had a clean build directory for gnucash prior to starting the compile. Thanks, Matt On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls wrote: I had a similar build failure on MacOS a few hours ago and pushed https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573 to fix it. Did your build have that commit? Regards, John Ralls > On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel > wrote: > > Hi responding to myself: > > First, forgot plain text in the first email, so I fixed the formatting in the > original below to make it easier to read. > Second, my system has both icu 61 which is the one explicitly required for > webkit as well as has icu 64 which was installed as part of the libxml2 > library. When I do a pkg-config, it finds the version 61 one. I suspect > this might be related to my problem, but I'm not experienced enough as a > programmer to figure out how to solve it. > > Thanks, > Matt > > > > On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via > gnucash-devel wrote: > > > Hi All, > I have recently worked on building GNUCash on windows to try to debug a > problem I've been having with my reports. I found a few things that look > like the script might need to be updated for (or I had something wrong in my > procedure). > > 1. I had to install some packages through pacman manually: > openssl-devel - this seemed to keep python's hashlib from working correctly > and not able to go very in the build process (I didn't start keeping notes > right at the beginning). > mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I > had to install it to continue. (I think I had to use this format as well to > install) > glib2-devel - Required for gnucash. > libxml2-devel - Required for gnucash > libxslt-devel - Required for gnucash > > 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup > powershell script. This failed due to a missing angleproject package. This > was not available in pacman anymore, so I ended up modifying > setup-mingw64.ps1 to add this to the install and re-ran it and it appears to > have installed correctly. > > But, that brings me to now where I'm stuck. I am getting the following error > when building: > [ 42%] Linking CXX shared library > ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function > `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: > undefined reference to > `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: > undefined reference to > `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: > undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) > const'collect2.exe: error: ld returned 1 exit status > > Any hints as to how to debug this one? > > Thanks, > Matt > ___ > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Yes I have that commit on my system and had a clean build directory for gnucash prior to starting the compile. Thanks,Matt On Thursday, August 15, 2019, 10:21:50 PM CDT, John Ralls wrote: I had a similar build failure on MacOS a few hours ago and pushed https://github.com/Gnucash/gnucash/commit/24d4576617995980c147bb49cacafe6f16978573 to fix it. Did your build have that commit? Regards, John Ralls > On Aug 15, 2019, at 7:21 PM, Matthew Forbis via gnucash-devel > wrote: > > Hi responding to myself: > > First, forgot plain text in the first email, so I fixed the formatting in the > original below to make it easier to read. > Second, my system has both icu 61 which is the one explicitly required for > webkit as well as has icu 64 which was installed as part of the libxml2 > library. When I do a pkg-config, it finds the version 61 one. I suspect > this might be related to my problem, but I'm not experienced enough as a > programmer to figure out how to solve it. > > Thanks, > Matt > > > > On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via > gnucash-devel wrote: > > > Hi All, > I have recently worked on building GNUCash on windows to try to debug a > problem I've been having with my reports. I found a few things that look > like the script might need to be updated for (or I had something wrong in my > procedure). > > 1. I had to install some packages through pacman manually: > openssl-devel - this seemed to keep python's hashlib from working correctly > and not able to go very in the build process (I didn't start keeping notes > right at the beginning). > mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I > had to install it to continue. (I think I had to use this format as well to > install) > glib2-devel - Required for gnucash. > libxml2-devel - Required for gnucash > libxslt-devel - Required for gnucash > > 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup > powershell script. This failed due to a missing angleproject package. This > was not available in pacman anymore, so I ended up modifying > setup-mingw64.ps1 to add this to the install and re-ran it and it appears to > have installed correctly. > > But, that brings me to now where I'm stuck. I am getting the following error > when building: > [ 42%] Linking CXX shared library > ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function > `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: > undefined reference to > `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: > undefined reference to > `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: > C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: > undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) > const'collect2.exe: error: ld returned 1 exit status > > Any hints as to how to debug this one? > > Thanks, > Matt > ___ > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building on Windows
Hi responding to myself: First, forgot plain text in the first email, so I fixed the formatting in the original below to make it easier to read. Second, my system has both icu 61 which is the one explicitly required for webkit as well as has icu 64 which was installed as part of the libxml2 library. When I do a pkg-config, it finds the version 61 one. I suspect this might be related to my problem, but I'm not experienced enough as a programmer to figure out how to solve it. Thanks, Matt On Thursday, August 15, 2019, 07:59:56 PM CDT, Matthew Forbis via gnucash-devel wrote: Hi All, I have recently worked on building GNUCash on windows to try to debug a problem I've been having with my reports. I found a few things that look like the script might need to be updated for (or I had something wrong in my procedure). 1. I had to install some packages through pacman manually: openssl-devel - this seemed to keep python's hashlib from working correctly and not able to go very in the build process (I didn't start keeping notes right at the beginning). mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I had to install it to continue. (I think I had to use this format as well to install) glib2-devel - Required for gnucash. libxml2-devel - Required for gnucash libxslt-devel - Required for gnucash 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup powershell script. This failed due to a missing angleproject package. This was not available in pacman anymore, so I ended up modifying setup-mingw64.ps1 to add this to the install and re-ran it and it appears to have installed correctly. But, that brings me to now where I'm stuck. I am getting the following error when building: [ 42%] Linking CXX shared library ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: undefined reference to `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: undefined reference to `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) const'collect2.exe: error: ld returned 1 exit status Any hints as to how to debug this one? Thanks, Matt ___ 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
[GNC-dev] Building on Windows
Hi All, I have recently worked on building GNUCash on windows to try to debug a problem I've been having with my reports. I found a few things that look like the script might need to be updated for (or I had something wrong in my procedure). 1. I had to install some packages through pacman manually:openssl-devel - this seemed to keep python's hashlib from working correctly and not able to go very in the build process (I didn't start keeping notes right at the beginning).mingw-w64-i686-gnutls - I don't remember the exact error this caused, but I had to install it to continue. (I think I had to use this format as well to install)glib2-devel - Required for gnucash.libxml2-devel - Required for gnucashlibxslt-devel - Required for gnucash 2. When I got to webkitgtk3, I noticed it hadn't installed during the setup powershell script. This failed due to a missing angleproject package. This was not available in pacman anymore, so I ended up modifying setup-mingw64.ps1 to add this to the install and re-ran it and it appears to have installed correctly. But, that brings me to now where I'm stuck. I am getting the following error when building:[ 42%] Linking CXX shared library ../../bin/libgncmod-engine.dllC:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/gncmod-engine.dir/objects.a(gnc-date.cpp.obj): in function `gnc_start_of_week':C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:214: undefined reference to `icu_64::Calendar::createInstance(UErrorCode&)'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:217: undefined reference to `u_errorName_64'C:/gcdev64/msys2/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/gcdev64/gnucash/maint/src/gnucash-git/libgnucash/engine/gnc-date.cpp:222: undefined reference to `icu_64::Calendar::getFirstDayOfWeek(UErrorCode&) const'collect2.exe: error: ld returned 1 exit status Any hints as to how to debug this one? Thanks, Matt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
