[GNC-dev] Using WSLg for building and using Gnucash

[Sumit Bhardwaj]

There have been some threads here about using WSL to use and develop Gnucash. I 
wanted to report back on my experience.

For the last few months, I have been using WSLg 
(https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps) to build 
Gnucash from maint and use it everyday for tracking my personal finances. This 
allows me to observe build breaks and I can ensure that Clang toolchain works 
without any issues.

Pros:
- My experience of building and using Gnucash is as straightforward as it can 
get. When there was a build break and I had some time, I was able to send a PR.
- VS Code works well with source and binary on WSL. I use that for my day job 
where I develop for Windows and Linux.
- If and when I have time, I can contribute which might be far less than what I 
hoped. ☹

Cons:
- WSLg doesn't build Windows binaries; Gnucash has to build Windows binaries 
for Windows users.
- WSLg is only available on Windows 11.
- WSLg is part of developer environment which might limit usage.


Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Fresh Windows build setup fails

[Sumit Bhardwaj]

I was trying around the same time as Robert on a fresh Windows machine and it 
failed as well. With the same message.

-Sumit

-Original Message-
From: gnucash-devel  
On Behalf Of Robert Fewell
Sent: Thursday, December 24, 2020 02:02
To: John Ralls 
Cc: gnucash-devel 
Subject: Re: [GNC-dev] Fresh Windows build setup fails

John,

Every thing above from 'My last attempt...' was done from the MINGW64 terminal 
prompt.

Regards,
Bob

On Thu, 24 Dec 2020 at 01:31, John Ralls  wrote:

>
>
> > On Dec 23, 2020, at 6:50 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> >
> > Hi,
> >
> > My Windows 10 hard drive failed which I thought would not be a big 
> > deal
> as
> > I only use it to build and test the windows build. After installing
> Windows
> > 10 and updating I grabbed the setup-mingw64.ps1 file and proceeded 
> > to recreate my build system.
> >
> > Unfortunately that did not work, tried the 32bit and 64bit versions 
> > which both failed. The first problem was that pkg-config --list-all 
> > would list all the packages with a starting forward slash with 
> > problems also in jhbuild.
> >
> > So tried another tact, I had an old backup from March which I 
> > restored
> and
> > then proceeded to update but that resulted in pacman listing loads 
> > of missing packages in the 'virtual world'
> >
> > My last attempt was to do the script manually, all OK till line 241 
> > where it installed mingw64/cmake and pkg-config. Once these were 
> > installed pkg-config --list-all would list with forward slash's. To 
> > overcome this I uninstalled them and installed msys versions and 
> > proceeded to the end of script.
> >
> > I have not checked the whether the boost version is correct for the
> webkit
> > version as to start with I just wanted a valid dependency.
> >
> > Changed to the gnucash-on-windows.git directory to start the build 
> > but
> that
> > failed as follows...
> >
> > Failed to 'import jhbuild' on line 15
> >   to fix I changed line 12 to sys.path.insert(0,
> > 'c:/gcdev64/src/jhbuild.git')
> >
> > Next was subprocess_win32 has no check_output  so added a line 
> > check_output = real_subprocess.check_output to subprocess_win32.py
> >
> > Which resulted in a string has no split method in systeminstall.py  
> > so changed shell_split = string.split to shell_split = str.split
> >
> > I am not sure these changes are correct as I know nothing about 
> > python
> but
> > I can now run...
> >
> > $ TARGET=gnucash-maint jhbuild -f jhbuildrc build Required packages:
> >  System installed packages which are too old:
> >(none)
> >  No matching system package installed:
> >make
> >gcrypt
> >pkg-config
> >gmp
> >git
> >boost
> >cmake
> >ninja
> >
> > The strange thing is that all these are installed as...
> > cmake --version gives 3.18.4, ninja --version gives 1.10.2
> >
> > So the question is, has anybody recently done a fresh build setup 
> > install and it worked or know how to fix.
>
> Bob,
>
> Are you trying to run MSYS2 commands from a CMD or Powershell window 
> instead of from an MinGW32/64 one?
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-develdata=04%7C01%7C%7C28d9450ad55d4a9a24f508d8a7f32a45%7C84df9e7fe9f640afb435%7C1%7C0%7C637444010130223888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DtWcT38sL5wOO0vMcHzlZXc0GeaM7LV4zwYjHoK5N9Y%3Dreserved=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] 64-bit nightly builds on Windows?

[Sumit Bhardwaj]

Hello,

I have been downloading and installing nightly Windows builds from 
https://code.gnucash.org/builds/win32/maint/. For my basic workflow, it's been 
working fine.

I noticed that the published builds are 32-bit. Why not 64-bit?

Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash 4.0 move windows support to only Windows 10?

[Sumit Bhardwaj]

John et al,

I looked through the release notes for 3.90x and noticed the support for 
Windows 8.1. Is there a specific reason to keep supporting Windows 8.1? Are 
there many users asking for support on Windows 8.1? For reference, Windows 10 
was released on Jul 29, 2015.

Selfishly, I want to see if I can use a clang with MSVC STL 
(https://github.com/microsoft/stl) to build gnucash on windows and I am not 
sure, what impact Windows 8.1 would have on that?

Thanks,
Sumit

-Original Message-
From: gnucash-devel  
On Behalf Of John Ralls
Sent: Monday, April 27, 2020 21:10
To: gnucash-devel 
Subject: [GNC-dev] GnuCash 3.90x Beta Schedule

I trust that everyone noticed that we released the first 3.90x test release 
this evening. We're aiming to release 4.0 on 28 June and there will be a final 
3.11 release of the 3.x branch at the same time. We don't want to risk blowing 
anything up in that last release, so please commit to maint only bug fixes that 
are straightforward and fix serious bugs. Everything else should go to master.

We'll have another test release at the end of May and impose feature freeze at 
that time, meaning that you have 5 weeks to finish up anything substantial and 
get it merged. June should be spent focussing on fixing any bugs reported 
against the new work and important fixes that don't involve major surgery. 
We'll do weekly releases through June to give testers plenty of opportunities 
to keep up with our progress.

One other date of note is string freeze on 14 June. No changes to translated 
strings between 14 June and 28 June to give translators a chance to give us the 
best possible translations--but be nice to them and try really hard to keep a 
lid on new strings from now on.

Any changes to the plan will go on the release schedule at 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.gnucash.org%2Fwiki%2FRelease_Scheduledata=02%7C01%7C%7C4e8672d90d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324sdata=dKwHmPl0QHVyDC893QYkbBzrNsGE%2FMw6J5pRpnmeVTI%3Dreserved=0.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-develdata=02%7C01%7C%7C4e8672d90d9b4f570cfd08d7eb2b7f6b%7C84df9e7fe9f640afb435%7C1%7C0%7C637236444364324324sdata=Dc8YbuNMsFbOF85eZ22HLEBaZlMCGLtnx37JWBD4Qdk%3Dreserved=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Building on Windows

[Sumit Bhardwaj]

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] build stats/badges for GNC maint, 3.6, 3.5 using Docker

[Sumit Bhardwaj]

> Microsoft Azure CI Pipelines offers a free tier of CI that could be  used and 
> 10x faster. I will explore their offering to see if it meets needs
Are you trying to establish Azure DevOps (ADO) CI pipeline? How is that 
exploration going? If you have something specific you want to try, I can try to 
take a stab as well.

> Windows builds. Thanks to JohnR and GeertJ, good progress has been made. I 
> have the responsibility for next steps. I need to return to my
   testing to see what is missing or not functioning.
Let me know if anything I can help here.

-Sumit

-Original Message-
From: gnucash-devel  
On Behalf Of Dale Phurrough via gnucash-devel
Sent: Wednesday, July 17, 2019 11:39
To: GnuCash Developer 
Subject: [GNC-dev] build stats/badges for GNC maint, 3.6, 3.5 using Docker

Hi all. I finished the second stage of my project to automate build/test of 
GnuCash with Docker. See the badges, drill down to logs and individual test 
results at
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiablodale.github.io%2Fgnucash-dev-docker%2Fdata=02%7C01%7C%7C2074620cc9f2494b4c8808d70ae63593%7C84df9e7fe9f640afb435%7C1%7C0%7C636989856173717376sdata=6%2FUvk%2Bhc8mJPW%2F10Zn1LDSSiTGRi0nK5w513DSylQqg%3Dreserved=0

In previous emails you read about the easy consistent GnuCash build/test with 
Docker.
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdiablodale%2Fgnucash-dev-dockerdata=02%7C01%7C%7C2074620cc9f2494b4c8808d70ae63593%7C84df9e7fe9f640afb435%7C1%7C0%7C636989856173717376sdata=AGah4xM21FewWFLz6mibjkvyFKQcSvbR182%2F2Y2uTXA%3Dreserved=0

   - Updated with clearer categorized build dependencies in Dockerfiles
   - Used these Docker containers to build/test across 14 distrib/versions
   of Linux
   - Containers can be built locally or downloaded from DockerHub
   - Automated build and tests using these containers via CI on AppVeyor
   - Transformed ctest results through XSLT to JUnit format
   - Exposed build and test results to badges

Still to do

   - Microsoft Azure CI Pipelines offers a free tier of CI that could be
   used and 10x faster. I will explore their offering to see if it meets needs
   - Windows builds. Thanks to JohnR and GeertJ, good progress has been
   made. I have the responsibility for next steps. I need to return to my
   testing to see what is missing or not functioning.
   - Watch and evaluate AppVeyor. I exposed several bugs in the AppVeyor
   offering as well as some limitations that required workarounds. I've
   reported the issues to the AppVeyor team.
   - Evaluate a switch to this docker build/test for GitHub PR testing. The
   existing Travis process being used has aged and doesn't test a full suite
   of functionality. With experience using AppVeyor and/or Microsoft CI, the
   core GnuCash team can evaluate switching away from the old Travis method.
   - Any related requests? Please send them to me.

--Dale
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-develdata=02%7C01%7C%7C2074620cc9f2494b4c8808d70ae63593%7C84df9e7fe9f640afb435%7C1%7C0%7C636989856173717376sdata=ZaKVbTKneiVgOtsIlGY23Q0rRoMaHrP2PJS2mOKPwbk%3Dreserved=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compilation error using cmake, but no error using autotools

[Sumit Bhardwaj]

Thanks Rob. That does it. And, yes, another PR:
https://github.com/Gnucash/gnucash/pull/197

If I get some time over the weekend, I will check through to make sure that
WITH_OFX and WITH_AQBANKING behave similarly. Unless someone beats me to it
:)

Thanks,
Sumit

On Sat, Sep 9, 2017 at 10:01 AM, Rob Gowin <r...@gowin.net> wrote:

>
>
> On Sep 9, 2017 11:32 AM, "Sumit Bhardwaj" <bhardw...@gmail.com> wrote:
>
> Thanks Rob. Just tried that route (cmake -D WITH_AQBANKING=OFF -D
> WITH_OFX=OFF -G Ninja ../gnucash/ && ninja && ninja check && ninja install).
>
> Ran into a new problem:
> ninja: error: '/home/bhardwajs/ac/devel/gnucash/cmake/ofx-gschema',
> needed by 'share/glib-2.0/schemas/gschemas.compiled', missing and no
> known rule to make it
>
> This directory (cmake/ofx-gschema) doesn't exist in master. Am I missing
> something?
>
> Thanks,
> Sumit
>
>
> Hi Sumit,
>
> (I apologize for misspelling your name in my previous reply.)
>
> It looks like you are running into more issues building with WITH_OFX=OFF.
> Try removing the 'ofx-gschema' item from https://github.com/
> Gnucash/gnucash/blob/master/cmake/CMakeLists.txt#L19. Another PR
> opportunity :-).
>
> Regards,
>
> Rob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compilation error using cmake, but no error using autotools

[Sumit Bhardwaj]

Thanks Rob. Just tried that route (cmake -D WITH_AQBANKING=OFF -D
WITH_OFX=OFF -G Ninja ../gnucash/ && ninja && ninja check && ninja install).

Ran into a new problem:
ninja: error: '/home/bhardwajs/ac/devel/gnucash/cmake/ofx-gschema', needed
by 'share/glib-2.0/schemas/gschemas.compiled', missing and no known rule to
make it

This directory (cmake/ofx-gschema) doesn't exist in master. Am I missing
something?

Thanks,
Sumit

On Sat, Sep 9, 2017 at 9:06 AM, Rob Gowin <r...@gowin.net> wrote:

>
>
> On Sep 9, 2017 10:37 AM, "Sumit Bhardwaj" <bhardw...@gmail.com> wrote:
>
> Hi,
>
> After pulling master, I decided to do a cmake build instead of the usual
> autotools. Ran into problems as detailed below. Autotools work smoothly. I
> would try to make more headway, but I don't understand scheme and a quick
> stack overflow search didn't show anything that I could try either.
>
> Thanks,
> Sumit
>
> Fedora 26
> guile version: 2.0.14
>
> Command:
> cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ && ninja
> check && ninja install
>
> Error message:
> [984/1000] Generating
> ../../../lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
> FAILED: lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
> cd /home/bhardwajs/ac/devel/build_gnucash/gnucash/report/business-reports
> && /usr/bin/cmake -E env
> LD_LIBRARY_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/
> home/bhardwajs/ac/devel/build_gnucash/lib/gnucash:
> GNC_UNINSTALLED=YES GNC_BUILDDIR=/home/bhardwajs/ac/devel/build_gnucash
> GUILE_LOAD_PATH=/home/bhardwajs/ac/devel/gnucash/gnucash/
> report/business-reports:/home/bhardwajs/ac/devel/build_
> gnucash/share/gnucash/scm
> GUILE_LOAD_COMPILED_PATH=/home/bhardwajs/ac/devel/build_gnuc
> ash/lib/gnucash/scm/ccache/2.0
> GNC_MODULE_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/
> home/bhardwajs/ac/devel/build_gnucash/lib/gnucash:
> /usr/bin/guile -e '(@@ (guild) main)' -s /usr/bin/guild compile -o
> /home/bhardwajs/ac/devel/build_gnucash/lib/gnucash/scm/ccach
> e/2.0/gnucash/report/invoice.go
> /home/bhardwajs/ac/devel/gnucash/gnucash/report/business-
> reports/invoice.scm
> Backtrace:
> In system/base/target.scm:
>   59: 19 [with-target "x86_64-redhat-linux-gnu" ...]
> In system/base/compile.scm:
>  152: 18 [compile-file
> "/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-
> reports/invoice.scm"
> ...]
>   43: 17 [call-once # system/base/compile.scm:56:5 ()>]
> In ice-9/boot-9.scm:
>  174: 16 [with-throw-handler #t ...]
> In system/base/compile.scm:
>   59: 15 [#]
>  155: 14 [#
> #]
>  218: 13 [read-and-compile # #:from ...]
>  234: 12 [lp (# # # # ...) # # 564234c77a00>]
>  182: 11 [lp (#) (use-modules #) ...]
> In ice-9/boot-9.scm:
> 2412: 10 [save-module-excursion # language/scheme/compile-tree-il.scm:29:3 ()>]
> In language/scheme/compile-tree-il.scm:
>   31: 9 [# language/scheme/compile-tree-il.scm:29:3 ()>]
> In ice-9/psyntax.scm:
> 1107: 8 [expand-top-sequence ((use-modules #)) () ((top)) ...]
>  990: 7 [scan ((use-modules (gnucash report standard-reports))) () ...]
>  279: 6 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
> In ice-9/boot-9.scm:
> 3622: 5 [process-use-modules (((gnucash report standard-reports)))]
>  712: 4 [map # (mif-args)> ((#))]
> 3623: 3 [#
> (#)]
> 2903: 2 [resolve-interface (gnucash report standard-reports) #:select ...]
> In unknown file:
>?: 1 [scm-error misc-error #f ...]
> In ice-9/boot-9.scm:
>  109: 0 [# args)> misc-error ...]
>
> ice-9/boot-9.scm:109:20: In procedure # ice-9/boot-9.scm:100:6 (thrown-k . args)>:
> ice-9/boot-9.scm:109:20: no code for module (gnucash report
> standard-reports)
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> Hi Simit,
>
> There are scheme dependency issues with CMake when you do 'ninja check'
> without first running plain 'ninja' first. So as a workaround until I can
> fix, do 'ninja && ninja check && ninja install'.
>
> Regards,
>
> Rob
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Compilation error using cmake, but no error using autotools

[Sumit Bhardwaj]

Hi,

After pulling master, I decided to do a cmake build instead of the usual
autotools. Ran into problems as detailed below. Autotools work smoothly. I
would try to make more headway, but I don't understand scheme and a quick
stack overflow search didn't show anything that I could try either.

Thanks,
Sumit

Fedora 26
guile version: 2.0.14

Command:
cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ && ninja
check && ninja install

Error message:
[984/1000] Generating
../../../lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
FAILED: lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
cd /home/bhardwajs/ac/devel/build_gnucash/gnucash/report/business-reports
&& /usr/bin/cmake -E env
LD_LIBRARY_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/home/bhardwajs/ac/devel/build_gnucash/lib/gnucash:
GNC_UNINSTALLED=YES GNC_BUILDDIR=/home/bhardwajs/ac/devel/build_gnucash
GUILE_LOAD_PATH=/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-reports:/home/bhardwajs/ac/devel/build_gnucash/share/gnucash/scm
GUILE_LOAD_COMPILED_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib/gnucash/scm/ccache/2.0
GNC_MODULE_PATH=/home/bhardwajs/ac/devel/build_gnucash/lib:/home/bhardwajs/ac/devel/build_gnucash/lib/gnucash:
/usr/bin/guile -e '(@@ (guild) main)' -s /usr/bin/guild compile -o
/home/bhardwajs/ac/devel/build_gnucash/lib/gnucash/scm/ccache/2.0/gnucash/report/invoice.go
/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-reports/invoice.scm
Backtrace:
In system/base/target.scm:
  59: 19 [with-target "x86_64-redhat-linux-gnu" ...]
In system/base/compile.scm:
 152: 18 [compile-file
"/home/bhardwajs/ac/devel/gnucash/gnucash/report/business-reports/invoice.scm"
...]
  43: 17 [call-once #]
In ice-9/boot-9.scm:
 174: 16 [with-throw-handler #t ...]
In system/base/compile.scm:
  59: 15 [#]
 155: 14 [#
#]
 218: 13 [read-and-compile # #:from ...]
 234: 12 [lp (# # # # ...) # #]
 182: 11 [lp (#) (use-modules #) ...]
In ice-9/boot-9.scm:
2412: 10 [save-module-excursion #]
In language/scheme/compile-tree-il.scm:
  31: 9 [#]
In ice-9/psyntax.scm:
1107: 8 [expand-top-sequence ((use-modules #)) () ((top)) ...]
 990: 7 [scan ((use-modules (gnucash report standard-reports))) () ...]
 279: 6 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
In ice-9/boot-9.scm:
3622: 5 [process-use-modules (((gnucash report standard-reports)))]
 712: 4 [map # ((#))]
3623: 3 [#
(#)]
2903: 2 [resolve-interface (gnucash report standard-reports) #:select ...]
In unknown file:
   ?: 1 [scm-error misc-error #f ...]
In ice-9/boot-9.scm:
 109: 0 [# misc-error ...]

ice-9/boot-9.scm:109:20: In procedure #:
ice-9/boot-9.scm:109:20: no code for module (gnucash report
standard-reports)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 Registry fields

[Sumit Bhardwaj]

Yes, please. This is different from GTK2 and disconcerting.


Thanks, Bob, for all the work so far for GTK3. So far, it's been a charm.

On Tue, Sep 5, 2017 at 9:49 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> I would like to confirm the behaviour of the new registry so that I can fix
> which ever way is correct, hopefully I can explain what I am seeing...
>
> If you mouse click on a field, say description, the text highlights and you
> are able to amend but you have no cursor. If you mouse click again, the
> entry becomes focused and you have a cursor, can add text but not delete
> any as the delete key, backspace and escape keys do not work.
>
> So do we want the entries to work when focused, I assume yes but thought I
> would ask ?
>
> Bob
> ___
> 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: Change Boost dependency to 1.54 or above?

[Sumit Bhardwaj]

Sounds good. I didn't realize Centos 7 was that far behind.

​Thanks,
Sumit​

On Sat, Sep 2, 2017 at 1:19 PM, Geert Janssens <geert.gnuc...@kobaltwit.be>
wrote:

> On zaterdag 2 september 2017 09:35:17 CEST Sumit Bhardwaj wrote:
> > Some time back, John had asked if we can move our Boost dependency to
> 1.54
> > or above so we can use Boost::log. I wanted to check back to see if we
> are
> > at a point where we can move Boost from 1.53 which is where we have it
> now.
> >
> > For reference, Fedora 22 shipped on May 26, 2015 with Boost version 1.58.
> > Fedora 26 has version 1.63 and Boost's latest version is 1.65.
> >
> Fedora is not a very good reference to determine the lower limit of package
> versions. It generally is very close to upstream.
>
> The distros to check are the long-term supported ones: RHEL/Centos, Ubuntu
> LTS, Debian stable,...
>
> For Ubuntu we currently still have to support 14.04LTS (Trusty), because
> that's what our test environment on Travis uses. That platform however is
> ok.
> It has boost 1.54 and 1.55 is available as well.
>
> Debian stable was at 1.55 last time I checked.
>
> RHEL/Centos 7 unfortunately are only at boost 1.53. There are ways to get
> more
> recent versions of boost there, but that would mean either building from
> scratch or configuring a foreign repository. If we require that we
> essentially
> state we're no longer supporting RHEL/Centos 7.
>
> I'm inclined not to do that and stick with 1.53 instead.
>
> Regards,
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: CMake failure with LIB_OFX OFF

[Sumit Bhardwaj]

You meant second. Right? :)

https://github.com/Gnucash/gnucash/pull/181

Thanks,
Sumit

On Sat, Sep 2, 2017 at 6:46 AM, John Ralls <jra...@ceridwen.us> wrote:

>
>
> > On Sep 2, 2017, at 12:22 AM, Sumit Bhardwaj <bhardw...@gmail.com> wrote:
> >
> > After pulling the latest master, I was able to make and make check using
> > autotools. However, cmake failed.
> >
> > With the command:
> >> cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ &&
> ninja
> > check && ninja install
> >
> > The error at the end is:
> > FAILED:
> > gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.
> dir/test-link.c.o
> > /usr/bin/cc -DHAVE_CONFIG_H -DHAVE_GUILE20  -Werror
> > -Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wunused
> > -Wmissing-prototypes -Wmissing-declarations  -Wno-unused
> > -Wno-deprecated-declarations -std=gnu11 -MD -MT
> > gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.
> dir/test-link.c.o
> > -MF
> > gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.
> dir/test-link.c.o.d
> > -o
> > gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.
> dir/test-link.c.o
> > -c
> > /home/bhardwajs/ac/devel/gnucash/gnucash/import-export/
> ofx/test/test-link.c
> > /home/bhardwajs/ac/devel/gnucash/gnucash/import-export/
> ofx/test/test-link.c:21:10:
> > fatal error: libofx/libofx.h: No such file or directory
> > #include 
> >  ^
> > compilation terminated.
> > [745/1002] Building CXX object
> > gnucash/import-export/csv-imp/CMakeFiles/gncmod-csv-import.
> dir/gnc-tx-import.cpp.o
> > ninja: build stopped: subcommand failed.
> >
> > Environment: Fedora 26
>
>
> Looks like an opportunity for your first PR! Obviously if WITH_OFX is off
> import-export/ofx shouldn’t build.
>
> Regards,
> John Ralls
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Change Boost dependency to 1.54 or above?

[Sumit Bhardwaj]

Some time back, John had asked if we can move our Boost dependency to 1.54
or above so we can use Boost::log. I wanted to check back to see if we are
at a point where we can move Boost from 1.53 which is where we have it now.

For reference, Fedora 22 shipped on May 26, 2015 with Boost version 1.58.
Fedora 26 has version 1.63 and Boost's latest version is 1.65.

Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

CMake failure with LIB_OFX OFF

[Sumit Bhardwaj]

After pulling the latest master, I was able to make and make check using
autotools. However, cmake failed.

With the command:
>cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ && ninja
check && ninja install

The error at the end is:
FAILED:
gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.dir/test-link.c.o
/usr/bin/cc -DHAVE_CONFIG_H -DHAVE_GUILE20  -Werror
-Wdeclaration-after-statement -Wno-pointer-sign -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations  -Wno-unused
-Wno-deprecated-declarations -std=gnu11 -MD -MT
gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.dir/test-link.c.o
-MF
gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.dir/test-link.c.o.d
-o
gnucash/import-export/ofx/test/CMakeFiles/test-link-ofx.dir/test-link.c.o
-c
/home/bhardwajs/ac/devel/gnucash/gnucash/import-export/ofx/test/test-link.c
/home/bhardwajs/ac/devel/gnucash/gnucash/import-export/ofx/test/test-link.c:21:10:
fatal error: libofx/libofx.h: No such file or directory
 #include 
  ^
compilation terminated.
[745/1002] Building CXX object
gnucash/import-export/csv-imp/CMakeFiles/gncmod-csv-import.dir/gnc-tx-import.cpp.o
ninja: build stopped: subcommand failed.

Environment: Fedora 26

Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring complete

[Sumit Bhardwaj]

On Fri, Aug 18, 2017 at 12:30 AM, Geert Janssens <geert.gnuc...@kobaltwit.be
> wrote:

> On vrijdag 18 augustus 2017 07:07:02 CEST Sumit Bhardwaj wrote:
> > Hi Geert,
> >
> > Coming back to this thread, I found some time today to see if I can build
> > using autotools. After pulling the latest master, "make" and "make check"
> > both worked. So, I am good building with autotools.
> >
> Good. Just to be clear - does this imply you were attempting a cmake build
> before when you reported your errors ?
>
​Couple of days ago, I was having problems with make check using autotools
as well. I haven't been able to get a clean build with cmake yet.​



> > For now, I will try to work on CSV importer if and when I find time -
> it's
> > going to be a challenge with a vacation coming soon.
> >
> > Thanks,
> > Sumit
> >
> Very well. Do report your progress regularly though to avoid double work.
>
Will do.​



> Enjoy your holidays!
>
Geert
>
​Thanks,
Sumit​

> On Tue, Aug 15, 2017 at 7:54 AM, Geert Janssens <
> geert.gnuc...@kobaltwit.be>
> > wrote:
> > > Hmm,
> > >
> > > And I meant to add, can you post the contents of the test logs for the
> > > failing
> > > tests ?
> > >
> > > You will find them in ../build_gnucash/libgnucash/engine/test/
> > > The logs are named after the tests so you'll be looking for
> > > test-test-extras.log
> > > test-account.log
> > > test-split.log
> > >
> > > Geert
> > >
> > > On dinsdag 15 augustus 2017 16:48:16 CEST Geert Janssens wrote:
> > > > Hi Sumit,
> > > >
> > > > Thanks for running the tests and reporting your issues. These are not
> > >
> > > known
> > >
> > > > problems. I have run both cmake and autotools builds before
> submitting
> > > > my
> > > > work and for both build systems I had all the tests succeeding. The
> > > > autotools build also completes fine on travis. So there is something
> > > > different in your environment. That can be either because you are on
> > >
> > > Fedora
> > >
> > > > 26 (I'm on 25 still) which comes with newer versions of several
> tools,
> > > > or
> > > > an unclean build environment.
> > > >
> > > > Last week Aaron Laws reported having issues on Arch linux due to it
> > >
> > > having
> > >
> > > > both guile 2.0 and 2.2. Perhaps that's biting you as well ?
> > > >
> > > > Geert
> > > >
> > > > On dinsdag 15 augustus 2017 08:22:04 CEST Sumit Bhardwaj wrote:
> > > > > Hi Geert,
> > > > >
> > > > > Pulled master and tried to build using autotoosls. As per your
> > >
> > > suggestion,
> > >
> > > > > I built in ../build_gnucash which is parallel to the top-level
> gnucash
> > > > > directory.
> > > > >
> > > > > make succeeded.
> > > > > make install succeeded as well.
> > > > > make check failed with 3 tests - error message below. Is this a
> known
> > > > > problem?
> > > > >
> > > > > I haven't tried building using cmake. My system configuration is
> also
> > > > > below
> > > > > (Fedora 26).
> > > > >
> > > > > Thanks,
> > > > > Sumit
> > > > >
> > > > > System config:
> > > > > --
> > > > >
> > > > >  gnucash version .. : 2.6.99
> > > > >  Build for host ... : x86_64-pc-linux-gnu
> > > > >  Optional components... :  dbi
> > > > >  Extra Warnings ... :  -Werror -Wdeclaration-after-statement
> > > > >
> > > > > -Wno-pointer-sign -D_FORTIFY_SOURCE=2
> > > > >
> > > > >  CPPFLAGS . :
> > > > >  CFLAGS ... : -g -O2 -std=gnu11
> > > > >  CXXFLAGS . : -g -O2
> > > > >  LDFLAGS .. :
> > > > >  prefix : /usr/local
> > > > >
> > > > > Test error
> > > > > ...
> > > > > mkdir -p  gnucash/engine/test
> > > > > ( cd gnucash/engine/test; for A in test-extras.scm ; do ln -s -f
> > > > > /home/bhardwajs/ac/devel/build_gnucash/../gnucash/
> libgnucash/engine/t
> > >

Re: Source directory restructuring complete

[Sumit Bhardwaj]

Hi Geert,

Coming back to this thread, I found some time today to see if I can build
using autotools. After pulling the latest master, "make" and "make check"
both worked. So, I am good building with autotools.

For now, I will try to work on CSV importer if and when I find time - it's
going to be a challenge with a vacation coming soon.

Thanks,
Sumit

On Tue, Aug 15, 2017 at 7:54 AM, Geert Janssens <geert.gnuc...@kobaltwit.be>
wrote:

> Hmm,
>
> And I meant to add, can you post the contents of the test logs for the
> failing
> tests ?
>
> You will find them in ../build_gnucash/libgnucash/engine/test/
> The logs are named after the tests so you'll be looking for
> test-test-extras.log
> test-account.log
> test-split.log
>
> Geert
>
> On dinsdag 15 augustus 2017 16:48:16 CEST Geert Janssens wrote:
> > Hi Sumit,
> >
> > Thanks for running the tests and reporting your issues. These are not
> known
> > problems. I have run both cmake and autotools builds before submitting my
> > work and for both build systems I had all the tests succeeding. The
> > autotools build also completes fine on travis. So there is something
> > different in your environment. That can be either because you are on
> Fedora
> > 26 (I'm on 25 still) which comes with newer versions of several tools, or
> > an unclean build environment.
> >
> > Last week Aaron Laws reported having issues on Arch linux due to it
> having
> > both guile 2.0 and 2.2. Perhaps that's biting you as well ?
> >
> > Geert
> >
> > On dinsdag 15 augustus 2017 08:22:04 CEST Sumit Bhardwaj wrote:
> > > Hi Geert,
> > >
> > > Pulled master and tried to build using autotoosls. As per your
> suggestion,
> > > I built in ../build_gnucash which is parallel to the top-level gnucash
> > > directory.
> > >
> > > make succeeded.
> > > make install succeeded as well.
> > > make check failed with 3 tests - error message below. Is this a known
> > > problem?
> > >
> > > I haven't tried building using cmake. My system configuration is also
> > > below
> > > (Fedora 26).
> > >
> > > Thanks,
> > > Sumit
> > >
> > > System config:
> > > --
> > >
> > >  gnucash version .. : 2.6.99
> > >  Build for host ... : x86_64-pc-linux-gnu
> > >  Optional components... :  dbi
> > >  Extra Warnings ... :  -Werror -Wdeclaration-after-statement
> > >
> > > -Wno-pointer-sign -D_FORTIFY_SOURCE=2
> > >
> > >  CPPFLAGS . :
> > >  CFLAGS ... : -g -O2 -std=gnu11
> > >  CXXFLAGS . : -g -O2
> > >  LDFLAGS .. :
> > >  prefix : /usr/local
> > >
> > > Test error
> > > ...
> > > mkdir -p  gnucash/engine/test
> > > ( cd gnucash/engine/test; for A in test-extras.scm ; do ln -s -f
> > > /home/bhardwajs/ac/devel/build_gnucash/../gnucash/libgnucash/engine/t
> > > est/$A . ; done )
> > > touch .scm-links
> > > echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
> > > test-test-extras
> > > echo 'export GNC_UNINSTALLED=yes;' >> test-test-extras
> > > echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
> > > ../../../../gnucash/libgnucash/engine/test/test-test-extras.scm -c "
> > > (exit (run-test))"' >> test-test-extras
> > > chmod a+x test-test-extras
> > > FAIL: test-test-extras
> > > echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
> > > test-account
> > > echo 'export GNC_UNINSTALLED=yes;' >> test-account
> > > echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
> > > ../../../../gnucash/libgnucash/engine/test/test-account.scm -c "(exi
> > > t (run-test))"' >> test-account
> > > chmod a+x test-account
> > > FAIL: test-account
> > > echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
> > > test-split
> > > echo 'export GNC_UNINSTALLED=yes;' >> test-split
> > > echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
> > > ../../../../gnucash/libgnucash/engine/test/test-split.scm -c "(exit
> > > (run-test))"' >> test-split
> > > chmod a+x test-split
> > > FAIL: test-split
> >
> >
> 
> 

Re: Source directory restructuring complete

[Sumit Bhardwaj]

Hi Geert,

Pulled master and tried to build using autotoosls. As per your suggestion,
I built in ../build_gnucash which is parallel to the top-level gnucash
directory.

make succeeded.
make install succeeded as well.
make check failed with 3 tests - error message below. Is this a known
problem?

I haven't tried building using cmake. My system configuration is also below
(Fedora 26).

Thanks,
Sumit

System config:
--
 gnucash version .. : 2.6.99
 Build for host ... : x86_64-pc-linux-gnu
 Optional components... :  dbi
 Extra Warnings ... :  -Werror -Wdeclaration-after-statement
-Wno-pointer-sign -D_FORTIFY_SOURCE=2
 CPPFLAGS . :
 CFLAGS ... : -g -O2 -std=gnu11
 CXXFLAGS . : -g -O2
 LDFLAGS .. :
 prefix : /usr/local


Test error
...
mkdir -p  gnucash/engine/test
( cd gnucash/engine/test; for A in test-extras.scm ; do ln -s -f
/home/bhardwajs/ac/devel/build_gnucash/../gnucash/libgnucash/engine/t
est/$A . ; done )
touch .scm-links
echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
test-test-extras
echo 'export GNC_UNINSTALLED=yes;' >> test-test-extras
echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
../../../../gnucash/libgnucash/engine/test/test-test-extras.scm -c "
(exit (run-test))"' >> test-test-extras
chmod a+x test-test-extras
FAIL: test-test-extras
echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
test-account
echo 'export GNC_UNINSTALLED=yes;' >> test-account
echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
../../../../gnucash/libgnucash/engine/test/test-account.scm -c "(exi
t (run-test))"' >> test-account
chmod a+x test-account
FAIL: test-account
echo 'export GNC_BUILDDIR="/home/bhardwajs/ac/devel/build_gnucash";' >
test-split
echo 'export GNC_UNINSTALLED=yes;' >> test-split
echo '/home/bhardwajs/ac/devel/build_gnucash/gnc-guile --debug -l
../../../../gnucash/libgnucash/engine/test/test-split.scm -c "(exit
(run-test))"' >> test-split
chmod a+x test-split
FAIL: test-split

Testsuite summary for GnuCash 2.6.99

...

On Mon, Aug 14, 2017 at 9:57 AM, Geert Janssens 
wrote:

> Hi,
>
> I have just pushed my directory restructuring branch to master as I
> announced
> last week.
>
> IMPORTANT: You should wipe out your existing build/install directory after
> pulling this new master. And if you are building in the source tree (which
> we
> don't advise) instead of having a separate build directory, be sure to run
> "make distclean" there *BEFORE* pulling this new master.
>
> Then proceed as usual, that is run autogen.sh/configure-with-options/make
> for
> an autotools
> based build or cmake-with-options/[make/ninja(-build)] for a cmake based
> build.
>
> The new directory structure is roughly as follows:
>
> * data
> Non-code items that get installed (like account charts, check formats,
> pixmaps)
> * libgnucash
> The core libraries which define our internal data structures and code to
> handle them. This holds the core-utils, gnc-module, engine (including qof),
> app-utils and a few smaller ones
> * gnucash
> The code for the gui application built on top of libgnucash. Here you'll
> find
> the directories gnome, gnome-utils, report, html, import-export,...
> * bindings
> Currently only the python bindings are here, in the future the guile
> bindings
> should be migrated here as well.
> * common
> Low level support code, mostly for debugging and testing (debug, test-
> core,...)
>
> In the restructuring, the cutecash project has been removed together with
> the
> gtkmm support library.
>
> A few other directories have been eliminated and their content moved to
> other
> locations:
> - src/bin -> gnucash (no more separate subdirectory)
> - src/optional: the python-bindings subdirectory has been moved to
> bindings,
> the only other subdir was gtkmm which has been dropped
> - src/plugins: the two real "plugins' in there were in fact import
> modules, so
> they have been moved to import-export. The example subdirectory (which is
> never built) is now a subdirectory of libgnucash/gnc-module
>
> Please report any problems you may experience with this new work.
>
> 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

Re: cmake failure (was:Re: Source directory restructuring)

[Sumit Bhardwaj]

Actually, I was using ninja when I ran into this problem. Here is the
sequence of commands that lead to the error:

$> pwd
devel/gnucash
$mkdir gbuild && cc gbuild
$ cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja .. && ninja check &&
ninja install

I am attaching po/missing.

Note that the following commands also didn't failed for the same reason.
$> pwd
devel/gnucash
$> cd .. && mkdir gbuild && cd gbuild
$> cmake -D WITH_AQBANKING=OFF -D WITH_OFX=OFF -G Ninja ../gnucash/ &&
ninja check && ninja install

Thanks,
Sumit

On Thu, Aug 10, 2017 at 6:09 AM, Geert Janssens 
wrote:

> On donderdag 10 augustus 2017 14:15:24 CEST Aaron Laws wrote:
> > I remember getting that error a long time ago, but I don't remember how
> to
> > fix it. I think it has something to do with deleting a generated file and
> > having make re-generate it? It seems like we have a generated file in
> > version control? Is POTFILES.in generated and version controlled for
> > example?
>
> It is, but that's not the problem. However your reply did ring a bell and
> here's the issue:
> If your build directory is a subdirectory of your source directory make
> check
> will fail because it will falsely believe the built files should be added
> to
> POTFILES.in. Building with ninja-build doesn't exhibit this issue so I
> assume
> it's a make quirk.
>
> The immediate solution is simple: choose a build directory that's not a
> subdirectory of your source directory. How to nudge cmake to deal with this
> properly may be another matter.
>
> Regards,
>
> Geert
>


missing
Description: Binary data
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Timeline and goals for Gnucash v 2.8

[Sumit Bhardwaj]

Apologies for the delay in responding. Gmail put this email in spam and
that has been happening a lot with Geert's emails. Not sure, what's
happening.

Looking at the list above:
- Where can I get details for the serious memory leak in SQL back-end and
what's a large book for that? My book is around 2MB, but it's not in SQL
back-end. So, I can try to work on that if it's large.
- For the corrupted data on save, that seems a Windows-specific bug (
https://bugzilla.gnome.org/show_bug.cgi?id=782144). I am not seeing that on
Fedora binaries I am building from master.
- For the clean-up, I am happy to take a look at cleaning up and adding
unit tests. Let me know which one you would like me to start with. My
preference would be CSV importer.

Thanks,
Sumit

On Thu, Aug 3, 2017 at 9:06 AM, Geert Janssens <geert.gnuc...@kobaltwit.be>
wrote:

> On donderdag 3 augustus 2017 17:42:29 CEST John Ralls wrote:
> > > On Aug 3, 2017, at 7:43 AM, Sumit Bhardwaj <bhardw...@gmail.com>
> wrote:
> > >
> > > Hello Devels,
> > >
> > > I have been following the threads for last few months and trying to
> get a
> > > sense of the timeline and what will be part of Gnucash 2.8 and I don't
> > > have
> > > a good sense. On IRC, John asked to email the DL so we can reach a
> > > conclusion.
> > >
> > > My personal interest in getting the clarity is to see how best I can
> > > contribute.
> >
> > Sumit,
> >
> > What's going into 2.8 is what's in master now, cleaned up and made ready
> for
> > release. We're still open to new feature contributions but I think that
> the
> > core devs will be focusing on getting what's in there now polished up for
> > release. For 2.6 we ran a 6-month alpha-beta release cycle, beginning in
> > July and culminating with the 2.6.0 release the last week of December.
> > We're not ready to do that first alpha release.
> >
> > The switch to Gtk3/Webkit4gtk3 led us to switch the Windows build system
> to
> > mingw64 from vanilla mingw because the former has many of our
> dependencies
> > already built. I've gotten it working on my local Windows VM and
> installed
> > it in the "official" windows VM that Derek hosts, where it hung. We
> > obviously need to be able to build Windows installers reliably before we
> > can start alpha releases.
> >
> > I know of two other problems: The SQL backend has a serious memory leak
> that
> > causes it to run out of memory and crash on large books and
> > https://bugzilla.gnome.org/show_bug.cgi?id=782144
> > <https://bugzilla.gnome.org/show_bug.cgi?id=782144>, corrupted data on
> > save. IMO both of those need to be resolved before we do a release.
> >
> > Regards,
> > John Ralls
>
> Adding to this here's what I still have on my todo for 2.8 (not
> necessarily in
> that order):
>
> 1. Reshuffle the directory structure of our sources. I have started a
> branch
> and I'm almost finished folding the remaining business subdirectories into
> the
> register and gnome directories respectively. I also want to fold qof back
> into
> the engine (the split off into an independent library hasn't worked out so
> I
> don't see a reason to keep it separated still. I'd like to do even more,
> but
> will talk about that in a separate mail as it requires some discussion.
>
> 2. A fix for https://bugzilla.gnome.org/show_bug.cgi?id=503722 (moving
> .gnucash to a proper location supported by the freedesktop spec). Aside
> from
> simply using another location, some migration code should be written to
> copy
> anything existing in .gnucash to the new directory.
>
> 3. clean ups in all major code changes I did for 2.8 (csv importer,
> register/
> gtk3). The csv importer for example needs a lot more unit testing.
>
> 4. If time permits fix building of the gnucash libs without gui. This
> should
> be a small one but can be very helpful in the context of the
> (python)bindings.
>
> And right now I'm tweaking cmake/autotools to have them generate the same
> POTFILES output. As things are now they use different sorting alghorithms
> so
> I'm seeing a lot of noise in commits when switching between the two build
> environments.
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Sumit Bhardwaj]

John and Geert,

As I remembered, I am still having problem with cmake. I have pasted the
error message below. Is this a known problem? If not, will it be better to
wait for Geert's restructuring and then try to fix it? For reference,
autotools work.

Thanks,
Sumit

​[3/942] cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake ...e -D
PO_DIR=/home/bhardwajs/ac/devel/gnucash/po -P check-po.cmake
FAILED: po/CMakeFiles/check-po
cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake -D
INTLTOOL_UPDATE=/usr/bin/intltool-update -D PO_DIR=/home/bhardwajs/ac/deve
l/gnucash/po -P check-po.cmake
The usage of POTFILES.ignore is deprecated. Please consider moving the
content of this file to POTFILES.skip.
The following files contain translations and are currently not in use.
Please
consider adding these to the POTFILES.in file, located in the po/ directory

If some of these files are left out on purpose then please add them to
POTFILES.skip instead of POTFILES.in. A file 'missing' containing this list
of left out files has been written in the current directory.
Please report to gnucash-devel@gnucash.org
CMake Error at check-po.cmake:22 (MESSAGE):
 POTFILES.in is missing files.  See 'missing' in
 /home/bhardwajs/ac/devel/gnucash/po


On Wed, Aug 9, 2017 at 11:54 AM, John Ralls <jra...@ceridwen.fremont.ca.us>
wrote:

>
> > On Aug 9, 2017, at 9:16 PM, Alex Aycinena <alex.aycin...@gmail.com>
> wrote:
> >
> >>
> >>
> >>
> >> -- Forwarded message --
> >> From: John Ralls <jra...@ceridwen.fremont.ca.us>
> >> To: Sumit Bhardwaj <bhardw...@gmail.com>
> >> Cc: gnucash-devel <gnucash-devel@gnucash.org>
> >> Bcc:
> >> Date: Tue, 8 Aug 2017 20:01:44 +0300
> >> Subject: Re: Source directory restructuring
> >>
> >>> On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj <bhardw...@gmail.com>
> wrote:
> >>>
> >>> John,
> >>>
> >>> If the plan is to dump autotools, should we ask also devs to make sure
> >> that
> >>> they can build using cmake? I have had problems in the past and
> >> therefore,
> >>> I have stuck with autotools so far.
> >>>
> >>> What are the things we want to confirm in the cmake toolchain?
> >>> cmake
> >>> cmake install
> >>> cmake check
> >>>
> >>> Anything else?
> >> Sumit,
> >>
> >> No. cmake  srcdir && make && make check && make install or (quite
> a
> >> bit faster) cmake -G Ninja  srcdir && ninja check && ninja
> install.
> >>
> >> You generally need to at least specify a -DCMAKE_INSTALL_PREFIX unless
> you
> >> want GnuCash installed in /usr/local which back in the day was a
> reasonable
> >> thing to do but isn't really anymore. Because of normal linker behavior
> and
> >> GnuCash's overuse of loadable modules you also need to uninstall before
> >> building, especially when changing branches. The incantation for that in
> >> cmake is xargs rm < install_manifest.txt.
> >>
> >> Geert and I use the cmake+ninja build system most of the time and the
> >> Windows automated build has been using it for just over a year. I think
> >> that it's well tested. There's a known problem that the dependency graph
> >> doesn't capture everything especially for some of the scheme modules so
> >> allowing too much parallelism (setting -j too high on a many-core
> machine)
> >> will try to build some things before their dependencies are done. That's
> >> not a blocker to dropping autotools. The only loose end at present is
> that
> >> there are still a few rough edges in the dist target that need to be
> >> cleaned up.
> >>
> >> Regards,
> >> John Ralls
> >>
> >>
> >
> > I switched to cmake and ninja a few months ago when I had trouble
> building
> > with autotools and I thought everything was working fine. I pushed a
> commit
> > and found that some changes to unit tests that I had made didn't work and
> > so I accidently broke the build. I had assumed that ninja check, which
> had
> > been successful, had run the unit tests and hadn't bother to check for
> > sure. I was finally able to get autotools to work by not including the
> > debug arg in configure and so was able to run the unit test, fix it and
> > push the fix. I have been using autotools since to make sure the tests
> are
> > all run.
> >
> > My question is whether cmake now runs all the same unit tests.
> >
>
> Alex,
>
> IIRC you flagged those tests as not run and Geert fixed them. Do you
> remember what they were?
>
> I think that cmake and autotools are running the same set of tests but I
> haven't done a test-by-test comparison in a while.
>
> Regards,
> John Ralls
>
>
> ___
> 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: Source directory restructuring

[Sumit Bhardwaj]

John,

If the plan is to dump autotools, should we ask also devs to make sure that
they can build using cmake? I have had problems in the past and therefore,
I have stuck with autotools so far.

What are the things we want to confirm in the cmake toolchain?
cmake
cmake install
cmake check

Anything else?

Thanks,
Sumit

On Tue, Aug 8, 2017 at 7:36 AM, John Ralls 
wrote:

>
> > On Aug 8, 2017, at 10:29 AM, Geert Janssens 
> wrote:
> >
> > On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
> >> These are to be top-level directories, so the current src goes away,
> right?
> >> The rest assumes that to be the case.
> >>
> > Yes, I would drop src.
> >
> >> Let's call the libgnucash directory libgnucash instead of just lib and
> keep
> >> lib as the place put code pinched from elsewhere like the bits of
> >> libgoffice.
> >>
> > That's reasonable.
> >
> >> I want to get rid of gnc-module too, but it's not easy.
> >>
> > Indeed. I didn't plan this in the first phase. Except perhaps for some
> low
> > hanging fruit (like what I did with a couple of reports subdirectories) I
> > don't think this is something to target for 2.8.
> >
> >> App-utils has stuff that belongs in libgnucash and other stuff (e.g.
> >> options) that belongs in the application directory (which I propose
> calling
> >> "gnucash" below). There's also code splattered all over everywhere else
> >> that belongs in libgnucash. How much of a prerequisite to rearrangement
> is
> >> getting the code in the right place?
> >>
> > There's a gui and non-gui aspect to the options. The gui aspect clearly
> should
> > go to the "gnucash" part. The non-gui aspect probably not. In my long
> term
> > idea libgnucash should be able to generate reports (but not display
> them) to
> > allow the bindings (and eventual smartphone apps) access to this
> feature. As
> > things stand now, the report system requires the options. We all agree of
> > course the options are currently a complicated mixture of C and guile
> code
> > which needs serious modernization. That will not be for 2.8.
> >
> > But your general message stands. Lots of code is in the wrong functional
> > source group. And there definitely won't be time to reorganize all of
> that.
> >
> >> I think that having separate documentation directories (there are two,
> doc
> >> and src/doc) is an abject failure from a maintenance standpoint. A lot
> of
> >> stuff was written 15-20 years ago and was marked obsolete 10 years ago
> >> because it's been left to rot. All documentation needs to be in the
> source
> >> files as Doxygen comments. We should look through the docs and src/docs
> >> stuff and copy anything that's still relevant into comments in the
> >> appropriate source files and delete the docs directories.
> >>
> > Good idea.
> >
> >> I'd prefer that the application code go into a directory named gnucash
> >> rather than "ui". I'm inclined toward removing cutecash entirely. It
> made
> >> sense for Christian to keep it in the Gnucash repository when we were
> using
> >> SVN, but now he should just publish it in his own Github repo.
> >>
> > I realize I'm somewhat hesitant to drop cutecash from the repo. It looks
> I'm a
> > bit emotionally attached to it (although I never used it and only built
> it
> > once to test). That's probably because it's a decent first attempt to
> use qt
> > instead of gtk. And qt for me is one of the few options that can bring
> us one
> > code base for all form factors. (Drifting off into dreaming about
> Utopia...)
> >
> > Anyway sticking with the current situation I believe you are right to
> consider
> > removing it. It's not maintained, and based on the soon to be obsolete
> Qt4 and
> > most importantly it can be recovered should we ever want to do so or are
> ready
> > to go the Qt way and need a base to start from.
> >
> >> The bindings are mostly (and should probably be entirely) libgnucash
> >> bindings. They really belong in libgnucash or failing that in their own
> >> TLD, not part of the application.
> >>
> > TLD then.
> >
> >> Reports might stand on their own as a separate dependency of gnucash or
> they
> >> could be a subdirectory of gnucash. The same is true of import-export.
> In
> >> one approach  the GUI parts of each would be part of the application
> while
> >> the functional bits would be part of libgnucash. Are the matchers
> >> libgnucash or gnucash?
> >>
> > Long term I would like to see the functional part of both reports and
> import/
> > export be part of libgnucash and the gui's go into gnucash. I think
> there are
> > use cases where smartphone apps and the bindings would benefit from this.
> >
> > For 2.8 that would again be too much work. For this initial step I'd
> consider
> > the plugins directory to be the location to store self-contained,
> loadable
> > modules. There are already a few smaller ones in there. I'd add the
> report and
> > import/export directories in there 

Re: Python bindings and Gtk3

[Sumit Bhardwaj]

Agree with Mike. GTK3 changes are looking fine. So far, only minor issues.

For the tab issue, can you share a screenshot or something to that effect?
I am on master build and have tabs on right-hand side as well, but it's
perfectly usable.

-Sumit

On Mon, Aug 7, 2017 at 2:32 PM, Mike Alexander  wrote:

> You may already know this, but the Python bindings done’t work in the
> current master branch (they still use Gtk2).  I made a brief attempt to fix
> this, but I don’t know either Python or Gtk3 well enough.
>
> I also noticed a cosmetic issue that you may not be aware of because I use
> a non-default window configuration.  I keep the tabs arranged along the
> right hand side of the  window.  In the Gtk3 version these tabs are about
> twice as high as previously.  This means that my tabs don’t fit along the
> side of the window without scrolling.  Before they took up about 2/3 of the
> window height.  This is obviously not a fatal problem, but it is annoying.
>
> In general, I’m impressed by how well this works given the magnitude of
> the change.  It’s going to be a big improvement.
>
>   Mike
>
> ___
> 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: Source directory restructuring

[Sumit Bhardwaj]

This sounds like a great plan to me. It will definitely make understanding
the code easier than the current state.

-Sumit

On Mon, Aug 7, 2017 at 7:23 AM, Derek Atkins  wrote:

> Sounds like a great plan to me!!!
>
> -derek
>
> Geert Janssens  writes:
>
> > So after my houskeeping message in which I have announced the changes to
> src/
> > business and src/libqof, I'd like to bring up my eventual goal for the
> source
> > tree.
> >
> > My main motivation to do all this restructuring is to simplify. There are
> > currently plenty of directories and I often have to guess where to
> expect a
> > file. The qof vs engine story was one example. Is gnc-date something for
> qof
> > or for engine ? I find myself regularly searching for a file in the wrong
> > directory.
> >
> > So here follows a first proposal for the directory structure I'm
> targetting:
> >
> > * data (for things like art, checks, account hierarchy templates,...)
> > * doc (for all documenation)
> > * lib (for all source required to build "libgnucash", see below)
> > * ui (for all the user interfaces the project currently supports)
> >
> > I am omitting some smaller directories here, such as util and macros.
> They
> > will probably stay on the current top level for now.
> >
> > I'm envisioning "libgnucash" as the core library that encapsulates all
> gnucash
> > related concepts (the accounting concepts such as transaction, split, as
> well
> > as the data backends). This library is what all applications in the
> gnucash
> > sphere should depend on to implement the "gnucash" experience. The most
> > obvious is of course the current gnucash as we know it. However at some
> point
> > this library should ideally also become the core of the Android app and
> *who
> > knows* one day an IOS app. And closer to the current state, it should
> also be
> > the library that the guile and python bindings depend on. So all
> functionality
> > encapsulated in one single library, the API. In practice I think the
> following
> > directories belong in this libgnucash: core-utils, gnc-module, engine,
> the
> > backends, app-utils. (Note I would like to get rid of gnc-module still,
> but
> > that's a whole other discussion and task).
> >
> > The ui directory will have a subdirectory for each user interface we
> support.
> > This is not necessarily a *graphical* user interface though. At this
> point
> > there are already a number of them:
> > gnucash
> > cutecash
> > bindings (with subdirectories for python and guile)
> >
> > The bulk of the other directories are support directories for one of the
> ui's
> > and I propose to make them subdirectories of each respective ui.
> >
> > For example gtkmm is only used by cutecash, so let's store it there
> (until
> > another ui would also require it, which I consider unlikely to happen
> still).
> >
> > The other directories (gnome-utils, gnome-search, gnome, register, html,
> > report, import-export,...) are all used only in the gnucash application
> and
> > hence should be moved there. In the move I'd like to try and reduce the 3
> > gnome* directories to one and call it gtk as we're not using any gnome
> > specific technology any more.
> >
> > In a later phase I think it would be nice if the core libgnucash could
> also
> > spit out html reports, but that would require us to refactor the report
> > modules, which I consider too much work to be done at the same time.
> When this
> > eventually gets done the non-ui part of the report system can then be
> added in
> > libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/
> ...).
> >
> > Feedback or questions ?
> >
> > Geert
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> >
>
> --
>Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>Member, MIT Student Information Processing Board  (SIPB)
>URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>warl...@mit.eduPGP key available
> ___
> 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

Timeline and goals for Gnucash v 2.8

[Sumit Bhardwaj]

Hello Devels,

I have been following the threads for last few months and trying to get a
sense of the timeline and what will be part of Gnucash 2.8 and I don't have
a good sense. On IRC, John asked to email the DL so we can reach a
conclusion.

My personal interest in getting the clarity is to see how best I can
contribute.

Thanks so much for keeping gnucash humming!
~Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Intended behavior of automatic decimal point (bug 120940)

[Sumit Bhardwaj]

Based on all this, I propose we remove auto-decimal feature in v2.8.

Meanwhile, I will look for another bug to fix. Feel free to point me to a
bug that could use some attention.

Thanks,
Sumit

On Thu, Jul 27, 2017 at 8:24 PM, John Ralls  wrote:

>
>
> > On Jul 27, 2017, at 6:27 PM, Eric Siegerman  wrote:
> >
> > On Thu, Jul 27, 2017 at 08:20:50AM +, David T. via gnucash-devel
> wrote:
> >> I think of the decimal placement as applying to the final number in the
> field
> >> (as a sort of edit mask, if you will), rather than a preprocessing
> function
> >> that would apply to every element in an equation.
> >
> > I'm not sure that would quite work either.
> >
> > Currently, for simple numbers with no arithmetic, "1000" gets
> > auto-decimal-pointed ("scaled" hereafter), but "4.50" doesn't,
> > which are both just what one wants.  The same should apply in
> > formulas (I think! -- but more about that at the end).  Assuming
> > two auto-decimal places, consider:
> >1000 + 4.50
> >
> > I (think I) want the first term to get scaled, but not the
> > second, giving a result of 14.50.
> >
> > OK, so how about we scale each term separately, so that:
> >1000 * 3 + 450 -> 34.50
> > but also:
> >1000 * 3 + 4.50 -> 34.50
> > ("->" meaning "yields a result of", since "=" just looks wrong
> > under the circumstances :-) ).
> >
> > But then:
> >10.00 * 3 + 4.50 -> 34.50
> > We didn't want to scale the first term after all.
> >
> > I've thought of a couple of different approaches:
> >  - scale each term's resulting value if the term only contains
> >integers:
> >1000*3 + 4000   -> 30 + 40  = 70.00
> >1000*3 + 4000.  -> 30 + 4000= 4030.00
> >1000*3. + 4000  -> 3000 + 40= 3040.00
> >1000*3. + 4000. -> 3000 + 4000  = 7000.00
> >
> >  - scale each term's *first* number if it's an integer,
> >but never second or subsequent numbers:
> >1000 * 3   -> 30
> >1000 * 3.  -> 30
> >1000. * 3  -> 3000
> >1000. * 3. -> 1000
> >This is based on the thought that ($20 * $3) is meaningless;
> >it only makes sense to multiply money by something that isn't
> >money
> >
> > But neither of those works in all situations.
> >
> >
> > The easiest way out, I think, is to never scale formulas at all,
> > only simple numbers.  So:
> >4000   -> 40.00 # as currently happens
> >40.-> 40.00 # likewise
> > But:
> >4000+1 -> 4001.00
> >
> > That's how my truly ancient copy of Excel behaves.  (I don't
> > have access to a modern one.)
> >
> >
> > Or perhaps: for formulas, scale the final result (as you say),
> > but only if *all* of the numeric values the user typed are
> > integers:
> >1000*3 + 4000   -> 70.00
> >1000*3 + 4000.  -> 7000.00
> >1000*3. + 4000  -> 7000.00
> >1000.*3 + 4000  -> 7000.00
> >
> > That could boil down to:
> >Scale the final result unless the original input string
> >contains any "."s (or ","s depending on locale)
> > (without even any need to worry whether it's a number or
> > a formula).
> >
> > But given that it's not entirely clear how even a simple:
> >1000 + 4.50
> > should behave, anything with any subtlety at all is going to want
> > a fair amount of testing to see whether people actually find it
> > usable.  So an unsubtle approach like "never scale formulas" is
> > probably the safest place to start.
>
> I agree that the only sane way to have auto-decimal is to disable it if
> the input is a formula. The other sane approach is to remove it completely.
>
> Regards,
> John Ralls
>
> ___
> 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

Intended behavior of automatic decimal point (bug 120940)

[Sumit Bhardwaj]

​Hi,

In an attempt to fix a long-standing bug (
https://bugzilla.gnome.org/show_bug.cgi?id=120940), I looked at the code
and have a question on intended behavior of automatic decimal point.

From the doc (http://gnucash.org/viewdoc.phtml?doc=help), I see this
description for automatic decimal point.
> *Automatic Decimal Point:* This option will automatically insert a
decimal point into numbers you type in.​

It's not clear from the help that "560" will be converted to "5.60" with
automatic decimal points set to 2. Is that the intended behavior? If so,
should we edit the help?

There is a bug in handling the fractions when auto-decimal points. I can
try to fix that, but wanted to get the developers' take on the intended
behavior first.

Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compile error on clean build on Fedora 26

[Sumit Bhardwaj]

John and Alex,

I had some problem compiling on clean Fedora 26 as well. I fixed and sent a
PR (https://github.com/Gnucash/gnucash/pull/160). Please have a look when
you get a chance.

Thanks,
Sumit

On Thu, Jul 20, 2017 at 3:42 PM, John Ralls  wrote:

>
> > On Jul 20, 2017, at 3:17 PM, Alex Aycinena 
> wrote:
> >
> > On a new clean clone on a Fedora 26 VM, with the following configure:
> >
> > ../gnucash-clean/configure
> > --srcdir=/home/gnucash-dev/gitcheckouts/gnucash-clean
> > --prefix=/opt/gnucash-git/gnucash-clean
> >
> > I get the following error on make:
> >
> > In file included from
> > /home/gnucash-dev/gitcheckouts/gnucash-clean/
> src/libqof/qof/guid.cpp:25:0:
> > /home/gnucash-dev/gitcheckouts/gnucash-clean/
> src/libqof/qof/guid.hpp:52:51:
> > error: dynamic exception specifications are deprecated in C++11
> > [-Werror=deprecated]
> > static GUID from_string (std::string const &) throw
> > (guid_syntax_exception);
> >   ^
> > /home/gnucash-dev/gitcheckouts/gnucash-clean/
> src/libqof/qof/guid.cpp:346:45:
> > error: dynamic exception specifications are deprecated in C++11
> > [-Werror=deprecated]
> > GUID::from_string (std::string const & str) throw (guid_syntax_exception)
> > ^
> > cc1plus: error: unrecognized command line option
> ‘-Wno-deprecated-register’
> > [-Werror]
> > cc1plus: all warnings being treated as errors
> > make[5]: *** [Makefile:757: guid.lo] Error 1
> > make[5]: Leaving directory
> > '/home/gnucash-dev/gitcheckouts/gnucash-clean-build/src/libqof/qof'
> >
> > Builds OK on Fedora 25 so osomething must have changed between the two.
>
> Yeah, gcc v7 has a lot more warnings about obsolete behavior. The
> committee decided that two C++99 features, throw specs and auto_ptr, were
> irretrievably bad ideas so it's kind of surprising that compilers haven't
> been complaining about them for longer.
>
> Grep found only that one, and I pushed a commit removing it. If you find
> more by all means remove them.
>
> Regards,
> John Ralls
>
> ___
> 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: Problem building master with autotools

[Sumit Bhardwaj]

Just did a fresh pull from gnucash/master (not a rebase).

Using autotools (./autogen.sh && ./configure --enable-compile-warnings &&
make) succeeded.

Make check failed. Fail message is below. I will try to look at it if I
have some time tonight.

-Sumit

./../../test-driver: line 107:  8259 Trace/breakpoint trap   (core dumped)
"$@" > $log_file 2>&1
FAIL: test-app-utils

Testsuite summary for GnuCash 2.6.99

# TOTAL: 7
# PASS:  6
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See src/app-utils/test/test-suite.log
Please report to gnucash-devel@gnucash.org

Makefile:1051: recipe for target 'test-suite.log' failed
make[5]: *** [test-suite.log] Error 1
make[5]: Leaving directory
'/home/bhardwajs/ac/devel/gnucash/src/app-utils/test'
Makefile:1157: recipe for target 'check-TESTS' failed
make[4]: *** [check-TESTS] Error 2
make[4]: Leaving directory
'/home/bhardwajs/ac/devel/gnucash/src/app-utils/test'
Makefile:1272: recipe for target 'check-am' failed
make[3]: *** [check-am] Error 2
make[3]: Leaving directory
'/home/bhardwajs/ac/devel/gnucash/src/app-utils/test'
Makefile:1026: recipe for target 'check-recursive' failed
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory '/home/bhardwajs/ac/devel/gnucash/src/app-utils'
Makefile:596: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory '/home/bhardwajs/ac/devel/gnucash/src'
Makefile:825: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1


On Mon, Jul 10, 2017 at 7:15 PM, Alex Aycinena <alex.aycin...@gmail.com>
wrote:

>
>
> On Jul 10, 2017 6:58 PM, "Sumit Bhardwaj" <bhardw...@gmail.com> wrote:
>
> I checked out master in the AM today and had a clean build (make and make
> install) on Fedora 25 using autotools. I can try again once I get to my
> personal machine.
>
> Are you doing make test here? I can try and report.
>
> Thanks,
> Sumit
>
> On Mon, Jul 10, 2017 at 6:38 PM, Alex Aycinena <alex.aycin...@gmail.com>
> wrote:
>
>> With a fresh checkout of master, I try to build with the autotools but I
>> get an error in linking test-import-pending-matches with test-engine-stuff
>> during make as follows:
>>
>> /usr/bin/ld:
>> ../../../src/engine/test-core/.libs/libgncmod-test-engine.a(
>> test-engine-stuff.o):
>> undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
>> /usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command
>> line
>> collect2: error: ld returned 1 exit status
>> Makefile:837: recipe for target 'test-import-pending-matches' failed
>>
>> I can build with cmake but I would like to run make check after an
>> autotools make because I think it runs different checks.
>>
>> Can anyone give me an idea of how to get this to work? This is Fedora 25.
>>
>> Thanks,
>>
>> Alex
>> ___
>> gnucash-devel mailing list
>> gnucash-devel@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
> No - I have a new check out and an empty build directory. I run autogen.sh
> then change to the build directory. I run config with a bunch of switches
> referring back to the main directory for source. Then I run make and get
> the error.
>
> Can't figure out why it stopped working suddenly a few weeks ago.
>
> Thanks.
>
> Alex
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Problem building master with autotools

[Sumit Bhardwaj]

I checked out master in the AM today and had a clean build (make and make
install) on Fedora 25 using autotools. I can try again once I get to my
personal machine.

Are you doing make test here? I can try and report.

Thanks,
Sumit

On Mon, Jul 10, 2017 at 6:38 PM, Alex Aycinena 
wrote:

> With a fresh checkout of master, I try to build with the autotools but I
> get an error in linking test-import-pending-matches with test-engine-stuff
> during make as follows:
>
> /usr/bin/ld:
> ../../../src/engine/test-core/.libs/libgncmod-test-engine.a(
> test-engine-stuff.o):
> undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
> /usr/lib64/libstdc++.so.6: error adding symbols: DSO missing from command
> line
> collect2: error: ld returned 1 exit status
> Makefile:837: recipe for target 'test-import-pending-matches' failed
>
> I can build with cmake but I would like to run make check after an
> autotools make because I think it runs different checks.
>
> Can anyone give me an idea of how to get this to work? This is Fedora 25.
>
> Thanks,
>
> Alex
> ___
> 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: gnucash master: Multiple changes pushed

[Sumit Bhardwaj]

 On Mon, Jul 7, 2014 at 11:38 AM, John Ralls jra...@ceridwen.us wrote:

 On Jul 7, 2014, at 4:03 PM, Sumit Bhardwaj bhardw...@gmail.com wrote:

 Hi John,

 Sumit,

 I don't understand how you concluded that the AM_CXXFLAGS are being
 included when make builds gfec.c, nor do I understand why you think that
 it's using g++. The command make emitted when it failed was:

  gcc -DHAVE_CONFIG_H -I. -I../.. -Wno-error=deprecated-declarations
 -I../../lib/libc -I../../src -I../../src -I../../src/gnc-module
 -I../../src/app-utils/calculation -I../../src/core-utils -I../../src/engine
 -I../../src/libqof/qof -I../../src/backend/xml -pthread
 -I/usr/include/guile/2.0 -pthread -I/usr/include/glib-2.0
 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/gtk-2.0
 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0
 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0
 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2
 -I/usr/include/libxml2 -I/usr/include/libxml2
 -DG_LOG_DOMAIN=\gnc.app-utils\ -Werror -Wdeclaration-after-statement
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused -Wmissing-prototypes
 -Wmissing-declarations -Wno-non-literal-null-conversion -Wno-unused -g -O2
 -MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c gfec.c  -fPIC -DPIC -o
 .libs/gfec.o


 Clearly showing that it's calling gcc and clearly not including
 -Wno-deprecated-register.


 Apologies for not being clear. This compile shouldn't cause problem if the
 compiler was gcc. My test

 gcc   -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations
 -Wno-non-literal-null-
 conversion -Wno-unused -g -O2 -Werror -D_FORTIFY_SOURCE=2 helloworld.c

 worked without any problems, but the test with g++ threw the error saying
 -Wno-non-literal-null-conversion is not a valid option.


 Yeah, I got that. What I don't understand is why you think that's germane
 when it's clearly gcc that's failing to compile gfec.c and it's clearly
 cc1, not cc1plus, that's rejecting the -Wno-non-literal-null-conversion
 argument.


My hypothesis is based on the experiment on the trivial helloworld.c with
gcc and g++. While gcc compiles and links with the
-Wno-non-literal-null-conversion argument, g++ doesn't.

My hypothesis for the fail step is that cc1plus is invoked in the
background which bonks with this argument. I will google to see if that's
the behavior in mixed (C and C++) codebases.

So adding actual code to be compiled doesn't make any difference, it still
 passes only to fail later. Rats.

Of course, we can drop this argument as a workaround. Barring that,
configure is setting CFLAGS and CXXFLAGS correctly.  Rats indeed!


 Regards,
 John Ralls


Cheers,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Multiple changes pushed

[Sumit Bhardwaj]

Hi John,

That works - to an extent. gcc fails and the current configuration is:
 -Werror -Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURCE=2

Configure doesn't fail, but that the flags are far fewer than earlier. Is
this, what we want to go ahead with?

If anyone wants to look at the changes in
macros/m4_ax_check_compile_flag.m4 and configure.ac, I have pushed the
changes to master  repo on my github (https://github.com/bhardwajs/gnucash).

Cheers,
Sumit

P.S. - Apologies for a two-month hiatus. Work drained a lot of time and
energy. Should be better now. :)

On Sun, Jul 6, 2014 at 1:05 AM, John Ralls jra...@ceridwen.us wrote:


 On Jul 5, 2014, at 11:34 PM, Sumit Bhardwaj bhardw...@gmail.com wrote:

  Sure, John. Here you go. Interestingly, I didn't find conftest.c in the
 directory tree.
 
  'tree | grep conftest.c' gave no output.
 
  Thanks,
  Sumit
 
  configure:25408: checking whether C++ compiler accepts
 -Wno-deprecated-register
  configure:25427: g++ -c -g -O2 -std=gnu++11 -Werror
 -Wno-deprecated-register  conftest.cpp 5
  configure:25427: $? = 0
  configure:25435: result: yes
  configure:25449: checking whether C compiler accepts
 -Wno-non-literal-null-conversion
  configure:25468: gcc -c -g -O2 -Werror -Wno-non-literal-null-conversion
  conftest.c 5
  configure:25468: $? = 0
  configure:25476: result: yes
  configure:25484: checking what extra warning flags to pass to the C
 compiler
  configure:25547: gcc -c  -Wall -Wunused -Wmissing-prototypes
 -Wmissing-declarations  -Wno-non-literal-null-conversion -Wno-unused -g -O2
 -Werror -D_FORTIFY_SOURCE=2  conftest.c 5
  configure:25547: $? = 0
  configure:25560: result:  -Werror -Wdeclaration-after-statement
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2
  configure:25697: checking that generated files are newer than configure
  configure:25703: result: done
  configure:25835: creating ./config.status

 Interesting. I suspect that AX_CHECK_COMPILE_FLAG isn't getting cc1
 invoked, only cpp, because it passes in an effectively empty program.

 Try editing macros/m4_ax_check_compile_flag.m4 so that
   AC_COMPILE_IFELSE([m4_default([$5],[AC_LANG_PROGRAM()])],
 becomes
   AC_COMPILE_IFELSE([m4_default([$5],[AC_LANG_PROGRAM(
 [[const char hw[] = Hello, World\n;]],
 [[fputs (hw, stdout);]])]))])],

 and see if that will get it to fail in configure. You'll need to re-run
 autogen.sh to pull the modified macro into configure.

 Regards,
 John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Multiple changes pushed

[Sumit Bhardwaj]

Just a quick note on my problems with compiling master today with
Wno-non-literal-null-conversion.

Compile kept on failing with the error message gcc error: unrecognized
command line option referring to the Wno-non-literal-null-conversion flag.
My gcc version is 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

Commenting out this warning gave me a clean build. For now, I have
commented this in my local gnucash and in the local github directory.
#AX_CHECK_COMPILE_FLAG([-Wno-non-literal-null-conversion],
#[AM_CFLAGS=${AM_CFLAGS} -Wno-non-literal-null-conversion],
#[], [-Werror])

gcc man page doesn't list this warning as an option either. Not sure what's
going on. Will try to look tomorrow.

Thanks,
Sumit

P.S. - maint had same problem.

On Fri, Jul 4, 2014 at 7:30 AM, Geert Janssens janssens-ge...@telenet.be
wrote:

 On Friday 04 July 2014 03:03:27 jra...@ceridwen.us wrote:
   On July 3, 2014 at 5:22 PM Geert Janssens janssens-ge...@telenet.be
 wrote:
On Thursday 03 July 2014 20:07:46 John Ralls wrote:
 On Jul 3, 2014, at 7:25 PM, Geert Janssens
 janssens-ge...@telenet.be  
 wrote:
  Same issue but this time it may need some more careful testing.
  TXN_TYPE_NONE may be used in other locations where '\0' is
  assumed
  instead of NULL (guile comes to mind). I don't have time to go
  deeper into this right now so I'll just revert back to gcc for
  the
  time being.
 
  John, you don't *have* to fix this while you're on holidays :).
  There is an easy alternative and you can revisit it later if
  you
  like.
 
  Oh, just a side question: do we want maint to be buildable with
  clang as well ? If so we may need to backport (cherry-pick) the
  current round of fixes.

 Maybe you should just add -Wno-non-literal-null-conversion to
 CFLAGS.
 Copy the code I wrote yesterday for -Wno-deprecated-register
 without
 the AC_LANG([C++]) block.
  
I could do that but prefer not to until we know for sure the
warning is
   irrelevant. I can imagine clang doesn't throw this warning just for
   fun. Perhaps what we did was generally accepted before but is now
   considered risky ? I don't know. If we can avoid the warnings by
   small code modifications I'd prefer that approach.
 snip
 
  That's one way of looking at it, though there have been complaints
  that Clang enforces a particular coding style via somewhat bogus
  errors and warnings. In C 0, '\0', FALSE, and NULL are just different
  ways of saying the same thing; in C++11 we should say nullptr when we
  mean a null pointer, but for C code I think it's an unnecessary
  exercise to go through the code to make sure we always use NULL.
 
 With that you just did the analysis I was suggesting. I think you are
 right that in this case
 the warning is just too cautious and not useful in our code.

 So I have chosen to disable it (on condition the current compiler
 understands it) as you
 proposed.

 The maint backporting still needs to be done though.

 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

Re: gnucash master: Multiple changes pushed

[Sumit Bhardwaj]

Hi John,

It fails in first C compilation. I do have to do a make disclean to get
the error. Rebuilding with just uncommenting in configure doesn't throw
error which is why I didn't see it earlier. I have pasted the error stack
below.

Do let me know if you want me to do any more experiments. For now, I will
comment that line in configure.ac and rebuild the master.

Thanks,
Sumit

/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../..  -Wno-error=deprecated-declarations -I../../lib/libc -I../../src
-I../../src -I../../src/gnc-module -I../../src/app-utils/calculation
-I../../src/core-utils -I../../src/engine -I../../src/libqof/qof
-I../../src/backend/xml -pthread -I/usr/include/guile/2.0   -pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -pthread
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libxml2
-DG_LOG_DOMAIN=\gnc.app-utils\  -Werror -Wdeclaration-after-statement
-Wno-pointer-sign -D_FORTIFY_SOURCE=2  -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations  -Wno-non-literal-null-conversion -Wno-unused -g -O2
-MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c -o gfec.lo gfec.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
-Wno-error=deprecated-declarations -I../../lib/libc -I../../src -I../../src
-I../../src/gnc-module -I../../src/app-utils/calculation
-I../../src/core-utils -I../../src/engine -I../../src/libqof/qof
-I../../src/backend/xml -pthread -I/usr/include/guile/2.0 -pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libxml2
-DG_LOG_DOMAIN=\gnc.app-utils\ -Werror -Wdeclaration-after-statement
-Wno-pointer-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wno-non-literal-null-conversion -Wno-unused -g -O2
-MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c gfec.c  -fPIC -DPIC -o
.libs/gfec.o
gfec.c: In function 'gfec_catcher':
gfec.c:79:13: warning: 'scm_internal_stack_catch' is deprecated (declared
at /usr/include/guile/2.0/libguile/deprecated.h:648)
[-Wdeprecated-declarations]
 scm_internal_stack_catch(SCM_BOOL_T,
 ^
gfec.c: In function 'gfec_eval_file':
gfec.c:135:5: warning: 'scm_internal_stack_catch' is deprecated (declared
at /usr/include/guile/2.0/libguile/deprecated.h:648)
[-Wdeprecated-declarations]
 result = scm_internal_stack_catch(SCM_BOOL_T,
 ^
gfec.c: In function 'gfec_eval_string':
gfec.c:173:5: warning: 'scm_internal_stack_catch' is deprecated (declared
at /usr/include/guile/2.0/libguile/deprecated.h:648)
[-Wdeprecated-declarations]
 result = scm_internal_stack_catch(SCM_BOOL_T,
 ^
gfec.c: In function 'gfec_apply':
gfec.c:216:5: warning: 'scm_internal_stack_catch' is deprecated (declared
at /usr/include/guile/2.0/libguile/deprecated.h:648)
[-Wdeprecated-declarations]
 result = scm_internal_stack_catch(SCM_BOOL_T,
 ^
gfec.c: At top level:
cc1: error: unrecognized command line option
-Wno-non-literal-null-conversion [-Werror]
cc1: all warnings being treated as errors
make[4]: *** [gfec.lo] Error 1
make[4]: Leaving directory `/home/bhardwajs/ac/devel/gnucash/src/app-utils'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/bhardwajs/ac/devel/gnucash/src/app-utils'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/bhardwajs/ac/devel/gnucash/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bhardwajs/ac/devel/gnucash'
make: *** [all] Error 2


On Sat, Jul 5, 2014 at 12:09 AM, jra...@ceridwen.us jra...@ceridwen.us
wrote:



 On July 5, 2014 at 2:43 AM Sumit Bhardwaj bhardw...@gmail.com wrote:

   Just a quick note on my problems with compiling master today with
 Wno-non-literal-null-conversion.

  Compile kept on failing with the error message gcc error: unrecognized
 command line option referring to the Wno-non-literal-null-conversion flag.
 My gcc version is 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)
  Commenting out this warning gave me a clean build. For now, I have
 commented this in my local gnucash and in the local github directory.
#AX_CHECK_COMPILE_FLAG([-Wno-non-literal-null-conversion],
 #[AM_CFLAGS=${AM_CFLAGS} -Wno-non-literal-null-conversion],
 #[], [-Werror

Re: gnucash master: Multiple changes pushed

[Sumit Bhardwaj]

Sure, John. Here you go. Interestingly, I didn't find conftest.c in the
directory tree.

'tree | grep conftest.c' gave no output.

Thanks,
Sumit

configure:25408: checking whether C++ compiler accepts
-Wno-deprecated-register
configure:25427: g++ -c -g -O2 -std=gnu++11 -Werror
-Wno-deprecated-register  conftest.cpp 5
configure:25427: $? = 0
configure:25435: result: yes
configure:25449: checking whether C compiler accepts
-Wno-non-literal-null-conversion
configure:25468: gcc -c -g -O2 -Werror -Wno-non-literal-null-conversion
conftest.c 5
configure:25468: $? = 0
configure:25476: result: yes
configure:25484: checking what extra warning flags to pass to the C compiler
configure:25547: gcc -c  -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations  -Wno-non-literal-null-conversion -Wno-unused -g -O2
-Werror -D_FORTIFY_SOURCE=2  conftest.c 5
configure:25547: $? = 0
configure:25560: result:  -Werror -Wdeclaration-after-statement
-Wno-pointer-sign -D_FORTIFY_SOURCE=2
configure:25697: checking that generated files are newer than configure
configure:25703: result: done
configure:25835: creating ./config.status

On Sat, Jul 5, 2014 at 12:17 PM, jra...@ceridwen.us jra...@ceridwen.us
wrote:



 On July 5, 2014 at 11:35 AM Sumit Bhardwaj bhardw...@gmail.com wrote:

   Hi John,

  It fails in first C compilation. I do have to do a make disclean to get
 the error. Rebuilding with just uncommenting in configure doesn't throw
 error which is why I didn't see it earlier. I have pasted the error stack
 below.

 Do let me know if you want me to do any more experiments. For now, I will
 comment that line in configure.ac and rebuild the master.

  Thanks,
 Sumit

 /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
 -I../..  -Wno-error=deprecated-declarations -I../../lib/libc -I../../src
 -I../../src -I../../src/gnc-module -I../../src/app-utils/calculation
 -I../../src/core-utils -I../../src/engine -I../../src/libqof/qof
 -I../../src/backend/xml -pthread -I/usr/include/guile/2.0   -pthread
 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -pthread
 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
 -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16
 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libxml2
 -DG_LOG_DOMAIN=\gnc.app-utils\  -Werror -Wdeclaration-after-statement
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2  -Wall -Wunused -Wmissing-prototypes
 -Wmissing-declarations  -Wno-non-literal-null-conversion -Wno-unused -g -O2
 -MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c -o gfec.lo gfec.c
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
 -Wno-error=deprecated-declarations -I../../lib/libc -I../../src -I../../src
 -I../../src/gnc-module -I../../src/app-utils/calculation
 -I../../src/core-utils -I../../src/engine -I../../src/libqof/qof
 -I../../src/backend/xml -pthread -I/usr/include/guile/2.0 -pthread
 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread
 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
 -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
 -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libpng16
 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libxml2
 -DG_LOG_DOMAIN=\gnc.app-utils\ -Werror -Wdeclaration-after-statement
 -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused -Wmissing-prototypes
 -Wmissing-declarations -Wno-non-literal-null-conversion -Wno-unused -g -O2
 -MT gfec.lo -MD -MP -MF .deps/gfec.Tpo -c gfec.c  -fPIC -DPIC -o
 .libs/gfec.o
 gfec.c: In function 'gfec_catcher':
 gfec.c:79:13: warning: 'scm_internal_stack_catch' is deprecated (declared
 at /usr/include/guile/2.0/libguile/deprecated.h:648)
 [-Wdeprecated-declarations]
  scm_internal_stack_catch(SCM_BOOL_T,
  ^
 gfec.c: In function 'gfec_eval_file':
 gfec.c:135:5: warning: 'scm_internal_stack_catch' is deprecated (declared
 at /usr/include/guile/2.0/libguile/deprecated.h:648)
 [-Wdeprecated-declarations]
  result = scm_internal_stack_catch(SCM_BOOL_T,
  ^
 gfec.c: In function 'gfec_eval_string':
 gfec.c:173:5: warning: 'scm_internal_stack_catch' is deprecated (declared
 at /usr/include/guile/2.0/libguile/deprecated.h:648)
 [-Wdeprecated-declarations]
  result = scm_internal_stack_catch(SCM_BOOL_T,
  ^
 gfec.c: In function 'gfec_apply':
 gfec.c:216:5: warning: 'scm_internal_stack_catch' is deprecated (declared
 at /usr/include/guile/2.0/libguile/deprecated.h:648)
 [-Wdeprecated-declarations]
  result = scm_internal_stack_catch(SCM_BOOL_T

Re: Boost on Fedora

[Sumit Bhardwaj]

Hi Alex,

'yum install boost-devel' worked for me.

Thanks,
Sumit

On Thu, Jun 19, 2014 at 2:55 PM, Alex Aycinena alex.aycin...@gmail.com
wrote:

 I have both Fedora 19 and 20 and on each, when I try to build gnucash I
 get:

   checking Boost = 1.50.0... checking build system type...
 x86_64-unknown-linux-gnu
   checking host system type... x86_64-unknown-linux-gnu
   checking for boostlib = 1.50.0... configure: We could not detect the
 boost libraries (version 1.50 or higher). If you have a staged boost
 library (still not installed) please specify $BOOST_ROOT in your
 environment and do not give a PATH to --with-boost option.  If you are sure
 you have boost installed, then check your version number looking in
 boost/version.hpp. See http://randspringer.de/boost for more
 documentation.
   no
   configure: error: Boost 1.50.0 or later was not found and is required to
 build GnuCash

 during configure. I have boost-1.53.0-14 installed on both systems. Does
 anyone know what I need to do to get gnucash to build?

 Thanks,

 Alex
 ___
 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

Hello Gnucash-Devel

[Sumit Bhardwaj]

Hi Everyone,

Having been a silent viewer on Devel list for some time, it's time for me
to introduce myself and see how I can contribute.

Quick intro: I live in the Valley, but my day job involves only Python
scripts. I am a long-time user of Gnucash (First transaction: Jul 8, 2004).

Programming experience: Almost exclusively C++. This has been the reason
why I didn't tinker with the codebase yet.

Michalis is working on bug cleanup. I can try to work with him so we can
get the bug list trimmed. Other option is to work with John on qof
development. Since that's in C++, I would prefer that.

Thoughts/comments? Looking forward to being an active participant.

Thanks,
Sumit
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: backend encryption / security

[Sumit Bhardwaj]

Merging threads from Christian and Michael.

My summary from the thread is that:
Password protection feature seems to be something that would be useful to
have. Encryption is better left to specific tools. This would be easy to
explain to users. From Derek's email, it's a good idea to go ahead.

Thoughts/comments?

Thanks,
Sumit

On Wed, May 7, 2014 at 11:22 AM, Christian Stimming
christ...@cstimming.dewrote:

 Hi Michalis,

 thanks a lot for your offer for help, and thanks for explaining your idea.

 Contrary to what some other developers replied, the feature is indeed
 welcomed
 by at least part of the developers and surely by many users. I've discussed
 this previously, see (as you have probably seen already)
 http://gnucash.uservoice.com/suggestions/1547269
 and the thread following of
 https://lists.gnucash.org/pipermail/gnucash-devel/2013-June/035754.html

 From the user's point of view, having the possibility for an access
 protection
 password does make some sense and to my understanding this particular user-
 level feature would also be welcomed for inside gnucash.

 The picture may be different, though, when talking about an integrated
 encryption feature in gnucash. I, for one, would welcome that feature as
 well,
 so to provide some more access protection against casual access by
 someone
 unauthorized (e.g. shared user account as explained in the uservoice
 comments). It remains an open question on how to explain the limits of this
 feature clearly enough to the user. I.e., facts such as encrypting the data
 file doesn't make the log files disappear and so on. If you can explain how
 your solution solves the user feature request of casual access protection,
 but
 without tricking users into a too self-confident feeling of security, I
 think
 this is a worthwhile feature.

 Best Regards,

 Christian


 Am Dienstag, 6. Mai 2014, 18:40:03 schrieb Michalis Kamprianis:
  Hi,
  I can see in uservoice, and I think frequently asked in lists, the
 request
  for encryption or password protection of the datafile.
 
  Regarding database backends, I believe that database encryption should be
  used if required, (although I understand that dbi may not be up to the
  task).
 
  Nevertheless, for xml backend, I think that I could try to implement an
 AES
  based encryption (on saving) and decryption (on opening), based on code
  from aescrypt. Aescrypt is available for unix, windows, mac, so the
  implementation should probably be portable across platforms. The code is
  some gpl and some freeware. Of course such a solution only protects data
 at
  rest (i.e. when data is read in memory it is not protected. Log files are
  not protected. User configuration files are not protected - at least
  initially, and so on) so it's not transforming gnucash to the most secure
  accounting software out there, but solves the problem with datafile
  misplacement or unwanted access.
 
  The thing is, (a) I don't know if you're interested and / or agree in
  implementing something like that, and (b) although I will probably manage
  to code the open and save routines, I'm not sure I will not get stuck
  somewhere, in which case it will either remain as an unfinished project,
 or
  I will need some help from somebody more experienced.
 
  Your thoughts?
 
  Regards
  Michalis
  ___
  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