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-win10&data=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942&sdata=TSQl1pt%2B1XoY%2BP7MU%2BDFoneh4xUiiHZjypyf6YPJw%2Bk%3D&reserved=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%2Fvcpkg&data=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942&sdata=jnvhX6%2FizBe%2Fn5ERFcKGvs6WSjT1oZushJ%2BhHwhlQZY%3D&reserved=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-devel&data=02%7C01%7C%7C88908dd0227a45a5aae608d72a430bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637024339755320942&sdata=VYw%2BkXmJkGDKza2sikiz7aLNctqrpbdT119bqc2ndI4%3D&reserved=0 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Tax Tables
> On Aug 26, 2019, at 4:38 AM, Robert Fewell <14ubo...@gmail.com> wrote: > > Hi, > > I got distracted with these warning in my trace file as I like to build/run > with an empty one so I know any errors are down to me, these are from an > XML file with one open invoice when saving... > > * 11:58:50 WARN [taxtable_reset_refcount()] Fixing refcount on > taxtable 2dca815fad04436cbb5497517803cc79 (2 -> 1) > * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, > time64): assertion 'time != INT64_MAX' failed > * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, > time64): assertion 'time != INT64_MAX' failed > * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, > time64): assertion 'time != INT64_MAX' failed > * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, > time64): assertion 'time != INT64_MAX' failed > * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, > time64): assertion 'time != INT64_MAX' failed > > taking the time64 errors first, I was going to propose changing > maybe_add_time64 in gnc-invoice-xml-v2.cpp as follows... > >if (time) > to > if (time && time != INT64_MAX) >xmlAddChild (ptr, time64_to_dom_tree (tag, time)); > > any one see a problem with that ? 0 is a perfectly valid time64, representing 1970-01-01 00:00:00 UTC. Just check that it's not INT64_MAX. > > Now the first warning, this is due to the blank ledger entry in the open > invoice having the tax table cell filled in with the default one for that > customer and when one quits Gnucash the file save happens before the gui is > destroyed so the refcount will always be wrong by the number of open > invoices. > I did think about decreasing the refcount for the table in the blank entry > but that causes another issue with the value going below 0 unless it could > be increased before the ledger is destroyed. > > Can any one else see a way of fixing this, maybe just change it to an info > message ? > > On a similar note, if you save the file as a sqlite3 one, the refcount will > increase on every save / open by the number of open invoices which is down > to new entries with the default tax table being added to the 'entries > table' which also do not have an invoice value. > > No clue on this one. The SQL backend doesn't scrub the refcount which is why it's increasing. It's not at all clear to me that the taxtable refcount serves any useful purpose, but if it does it shouldn't be incremented in the blank entry. It should only be incremented when a new GncEntry or GncOwner referencing it is committed. 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 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
[GNC-dev] Tax Tables
Hi, I got distracted with these warning in my trace file as I like to build/run with an empty one so I know any errors are down to me, these are from an XML file with one open invoice when saving... * 11:58:50 WARN [taxtable_reset_refcount()] Fixing refcount on taxtable 2dca815fad04436cbb5497517803cc79 (2 -> 1) * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, time64): assertion 'time != INT64_MAX' failed * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, time64): assertion 'time != INT64_MAX' failed * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, time64): assertion 'time != INT64_MAX' failed * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, time64): assertion 'time != INT64_MAX' failed * 11:58:56 ERROR xmlNode* time64_to_dom_tree(const char*, time64): assertion 'time != INT64_MAX' failed taking the time64 errors first, I was going to propose changing maybe_add_time64 in gnc-invoice-xml-v2.cpp as follows... if (time) to if (time && time != INT64_MAX) xmlAddChild (ptr, time64_to_dom_tree (tag, time)); any one see a problem with that ? Now the first warning, this is due to the blank ledger entry in the open invoice having the tax table cell filled in with the default one for that customer and when one quits Gnucash the file save happens before the gui is destroyed so the refcount will always be wrong by the number of open invoices. I did think about decreasing the refcount for the table in the blank entry but that causes another issue with the value going below 0 unless it could be increased before the ledger is destroyed. Can any one else see a way of fixing this, maybe just change it to an info message ? On a similar note, if you save the file as a sqlite3 one, the refcount will increase on every save / open by the number of open invoices which is down to new entries with the default tax table being added to the 'entries table' which also do not have an invoice value. No clue on this one. Regards, Bob ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Need help - several tests fail
Op zondag 25 augustus 2019 17:43:31 CEST schreef John Ralls: > > On Aug 25, 2019, at 3:39 AM, Christian Gruber > > wrote:> > > Am 22.08.19 um 09:21 schrieb Geert Janssens: > >> Op donderdag 22 augustus 2019 05:37:12 CEST schreef John Ralls: > On Aug 21, 2019, at 3:28 PM, Christian Gruber > > wrote: > > Ok, that was a useful hint. Clearing the guile cache helped. I'm one > step > further. I have no idea, what led to this situation. I couldn't > reproduce > this again. > > Next problem is that still several tests fail with the following > output: > > ERROR: no code for module (gnucash engine test srfi64-extras) > >>> > >>> Which means that they're not finding > >>> libgnucash/engine/test/srfi64-extras.scm or perhaps srfi64-extras.go Can > >>> you figure out why? It might help to run make with VERBOSE=1 so that the > >>> whole command is printed for each step or to switch to ninja which dumps > >>> any failed commands without being asked and is also about 10x faster > >>> than > >>> make. > >>> > >>> Regards, > >>> John Ralls > >> > >> It can also be an as of yet undiscovered build dependency issue (there > >> still are a few on maint). > >> > >> You didn't post any error output (or full build log) so it's hard to > >> tell. > >> In the build logs do you find a message logging the build of engine/test/ > >> srfi64-extras.go before you get your errors ? > >> > >> Geert > > > > I fixed the problem. It is a missing build dependency. I did only call > > "make check" directly after generating a fresh build dir with CMake. So > > not every dependency of the tests has been built yet, scm-srfi64-extras > > is one of them. After calling "make all" and then "make check" again and > > after installing missing french locale, all tests run successfully now. > > Maybe there are even more missing dependencies, which are all built with > > "make all". > > > > Is this a known issue, that the test applications are missing some > > required dependencies in the CMakeLists.txt? I'll have a look, what is > > actually missing and try to fix it. > We know that the dependency tree in the CMakeLists isn't exhaustive, but > Geert had the check target sorted last winter. The srfi64 tests were added > after that and I guess that some dependencies got missed then. Obviously > having a full dependency tree is more robust, especially if the source > directory layout changes so have at it! > > Regards, > John Ralls IIRC I ran into this before and fixed it on master while reorganizing the scheme sources recently. As the file changes in that restructuring were fairly big, I didn't attempt to backport useful bits to maint. And I can't reproduce this particular dependency issue on master any more (just ran into a new one though). So it may be a maint-only issue. 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 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
