Re: Source directory restructuring complete

[Geert Janssens]

On woensdag 16 augustus 2017 20:50:59 CEST Eric Theise wrote:
> On Wed, Aug 16, 2017 at 12:42 AM, Geert Janssens  > wrote:
> > > I now get as far as the "Making check in po" stage.
> > > 
> > > ...
> > > 
> > > Making check in po
> > > rm -f missing notexist
> > > srcdir=../../po /usr/bin/intltool-update -m
> > 
> > All the missing file errors are the result of your build directory being a
> > subdirectory of your source directory (which you can also see in the line
> > above). This is a known intltool problem and has been the case before the
> > restructuring already.
> 
> That was the organization recommended in the "Using separate build
> directory" section of the wiki at https://wiki.gnucash.org/wiki/Building
> I've updated that section based on your comments.
> 

I didn't realize our own documentation suggested a setup that was known to be 
bad. Thanks for correcting this.

> > The easiest way to avoid it currently is to make sure your build directory
> > is
> > outside of the source directory, for example just aside it in the same
> > parent
> > directory like so
> > parent-dir/
> > parent-dir/gnucash
> > parent-dir/build
> > 
> > Also the warnings will continue to appear until you clean up the build
> > artifacts from your previous runs. From the POTFILES.in errors I deduce in
> > your case that means removing (at least) the current "build" directory and
> > the
> > current "share" directory in your source directory.
> 
> "share" was contained within "build", FWIW.
> 
> All looks good now, thanks.
> 

Glad to hear that and thanks for your feedback :)

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

Re: Source directory restructuring complete

[Geert Janssens]

On zondag 20 augustus 2017 14:28:06 CEST Robert Fewell wrote:
> OK found this one, pre-restructure there was a gncmod-business. that
> loaded the "gnucash/gnome-search" module but that has been removed so there
> is no search available at the moment. To fix, it can be added to the list
> of modules in gnucash-bin.c or should it go some where else ?
> 
> Bob
> 

Good catch!

And indeed the solution is to load the gnucash/gnome-search module in gnucash-
bin.c. I have committed a patch for that.

Thanks!

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

Re: Source directory restructuring complete

[Robert Fewell]

OK found this one, pre-restructure there was a gncmod-business. that
loaded the "gnucash/gnome-search" module but that has been removed so there
is no search available at the moment. To fix, it can be added to the list
of modules in gnucash-bin.c or should it go some where else ?

Bob

On 17 August 2017 at 12:55, Geert Janssens 
wrote:

> Hi Bob,
>
> I've been seeing this for quite some time now. Don't know where exactly it
> started. But it's definitely not local to you.
>
> Geert
>
> On donderdag 17 augustus 2017 13:12:34 CEST Robert Fewell wrote:
> > Just built with the new structure and I see the following in the trace
> > file...
> >
> > * 12:03:29  WARN  Could not locate module
> > gnucash/plugins/bi_import interface v.0
> > * 12:03:29  CRIT  gnc_search_core_register_type:
> assertion
> > 'typeTable' failed
> >
> > The first one was easy, I had a config.user file with the load comand for
> > bi_import, removed it and that one cleared, I assume that is not required
> > any more.
> >
> > The second comes from gnucash/gnome/top-level.c line 383 trying to
> register
> > gnc_search_owner_new
> >
> > Just wondering if other people see this or just local to me ?
> >
> > Bob
> >
> > On 17 August 2017 at 09:06, Geert Janssens 
> >
> > wrote:
> > > On donderdag 17 augustus 2017 10:02:02 CEST John Ralls wrote:
> > > > Nope, the problem is at
> > > > https://github.com/Gnucash/gnucash/blob/master/
> > >
> > > libgnucash/engine/qof-backen
> > >
> > > > d.cpp#L141:
> > > >  > >
> > > libgnucash/engine/qof-backe
> > >
> > > > nd.cpp#L141:> /* Darwin modules can have either .so or .dylib for a
> > >
> > > suffix
> > >
> > > > */
> > > >
> > > > if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
> > > >
> > > > g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
> > > >
> > > > {
> > > >
> > > > auto modname = g_strdup_printf ("lib%s.dylib", module_name);
> > > > g_free (fullpath);
> > > > fullpath = g_build_filename (directory, modname, NULL);
> > > > g_free (modname);
> > > >
> > > > }
> > > > auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);
> > > >
> > > > follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in
> an
> > > > autotools build and only before installation. Having
> directory="gnucash"
> > >
> > > is
> > >
> > > > correct after installation and always in a Cmake build. This will
> > >
> > > probably
> > >
> > > > break tests on an autotools build on Macs. I may decide I don't care
> and
> > > > that only CMake is supported there.
> > >
> > > Ah, I missed that. So the solution is simple IMO: fix the second
> creation
> > > of
> > > fullpath. Have it use absdir instead of directory. Of course that means
> > > absdir
> > > can only be freed after the Darwin test. I'll add push a change for
> you to
> > > test in a minute.
> > >
> > > 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: Source directory restructuring complete

[Sumit Bhardwaj]

On Fri, Aug 18, 2017 at 12:30 AM, Geert Janssens  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
> > > > > 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
> > > > > 

Re: Source directory restructuring complete

[Geert Janssens]

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 ?

> 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.

Enjoy your holidays!

Geert

> On Tue, Aug 15, 2017 at 7:54 AM, Geert Janssens 
> 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
> > 
> > 
> > 
> > 
> > > > Testsuite summary for GnuCash 2.6.99
> > 
> > 
> > 
> > 
> > > > ...
> > > > 
> > > > On Mon, Aug 14, 2017 at 9:57 AM, Geert Janssens
> > > > >
> > > > 
> > > > wrote:
> > > > > Hi,
> > 

Re: Source directory restructuring

[Geert Janssens]

On donderdag 17 augustus 2017 23:59:56 CEST Alex Aycinena wrote:
> I can also verify, from an earlier build, that test-import-pending-matches
> is run on my system with autotools. It didn't run after the latest git pull
> because of the test-backend-dbi failure in autotools as well.
> 
> That's a nice feature of the cmake route: if there is a failure in a test
> subsequent tests are run whereas in autotools make check stops and if there
> are other test failures you won't see them.
> 
You can get closer to this in autotools by adding the -k switch to make. In 
that case it will continue even after failure. It's not quite as nice as the 
cmake way because
- it will also continue in case of a compilation failure
- there's still lots of noise in between the test results so you have pages 
and pages of info to scroll through.

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

Re: Source directory restructuring

[John Ralls]

> On Aug 17, 2017, at 11:59 PM, Alex Aycinena <alex.aycin...@gmail.com> wrote:
> 
>> -- Forwarded message --
>> From: Geert Janssens <geert.gnuc...@kobaltwit.be>
>> To: gnucash-devel <gnucash-devel@gnucash.org>
>> Cc:
>> Bcc:
>> Date: Wed, 16 Aug 2017 12:44:52 +0200
>> Subject: Re: Source directory restructuring
>> On maandag 14 augustus 2017 02:59:58 CEST Alex Aycinena wrote:
>>> I did a test by test comparison using Testing/Temporary/LastTest.log also
>>> and I find there are three tests in autotools that are missing in cmake:
>>> 
>>> - src/engine/test/test-import-map
>>> - src/engine/test/test-engine
>>> - src/app-utils/test/test-app-utils
>>> 
>>> I couldn't map test # 77,
>>> src/import-export/test/test-import-pending-matches, to any in autotools.
>>> 
>>> Alex
>> 
>> Hi Alex,
>> 
>> I have added test-import-map and test-app-utils. On my system test-engine
>> is
>> running. Perhaps I fixed that already while restructuring the sources. I
>> don't
>> remember.
>> 
>> And test-import-pending matches is run via autotools on my system. It was
>> not
>> listed in the colored test output but it was run right after that. I have
>> tweaked the Makefile slightly so it now is part of the colored output and
>> hence more visible.
>> 
>> Can you verify this on your system as well ?
>> 
>> Geert
>> 
>> 
> 
> Geert,
> 
> I can verify that with cmake/ninja, the three tests are there. There was a
> test failure, however, in 21 - test-backend-dbi:
> 
> 21/103 Testing: test-backend-dbi
> 21/103 Test: test-backend-dbi
> Command:
> "/home/gnucash-dev/gitcheckouts/gnucash-clean-build/bin/test-backend-dbi"
> Directory:
> /home/gnucash-dev/gitcheckouts/gnucash-clean-build/libgnucash/backend/dbi/test
> "test-backend-dbi" start time: Aug 17 14:16 PDT
> Output:
> --
> /backend/dbi/adjust sql options string localtime: OK
> /backend/dbi/sqlite3/store_and_reload: test-backend-dbi:
> /usr/include/boost/variant/detail/forced_return.hpp:39: T
> boost::detail::variant::forced_return() [with T = const std::type_info&]:
> Assertion `false' failed.
> 
> Test time =   0.73 sec
> --
> Test Failed.
> "test-backend-dbi" end time: Aug 17 14:16 PDT
> "test-backend-dbi" time elapsed: 00:00:00
> 
> I can also verify, from an earlier build, that test-import-pending-matches
> is run on my system with autotools. It didn't run after the latest git pull
> because of the test-backend-dbi failure in autotools as well.
> 
> That's a nice feature of the cmake route: if there is a failure in a test
> subsequent tests are run whereas in autotools make check stops and if there
> are other test failures you won't see them.

Alex,

We know about the test-backend-dbi failure. Aaron Laws and I have been working 
on it for the last couple of days.

Regards,
John Ralls

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

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

Re: Source directory restructuring

[Alex Aycinena]

> -- Forwarded message --
> From: Geert Janssens <geert.gnuc...@kobaltwit.be>
> To: gnucash-devel <gnucash-devel@gnucash.org>
> Cc:
> Bcc:
> Date: Wed, 16 Aug 2017 12:44:52 +0200
> Subject: Re: Source directory restructuring
> On maandag 14 augustus 2017 02:59:58 CEST Alex Aycinena wrote:
> > I did a test by test comparison using Testing/Temporary/LastTest.log also
> > and I find there are three tests in autotools that are missing in cmake:
> >
> >  - src/engine/test/test-import-map
> >  - src/engine/test/test-engine
> >  - src/app-utils/test/test-app-utils
> >
> > I couldn't map test # 77,
> > src/import-export/test/test-import-pending-matches, to any in autotools.
> >
> > Alex
>
> Hi Alex,
>
> I have added test-import-map and test-app-utils. On my system test-engine
> is
> running. Perhaps I fixed that already while restructuring the sources. I
> don't
> remember.
>
> And test-import-pending matches is run via autotools on my system. It was
> not
> listed in the colored test output but it was run right after that. I have
> tweaked the Makefile slightly so it now is part of the colored output and
> hence more visible.
>
> Can you verify this on your system as well ?
>
> Geert
>
>

Geert,

I can verify that with cmake/ninja, the three tests are there. There was a
test failure, however, in 21 - test-backend-dbi:

21/103 Testing: test-backend-dbi
21/103 Test: test-backend-dbi
Command:
"/home/gnucash-dev/gitcheckouts/gnucash-clean-build/bin/test-backend-dbi"
Directory:
/home/gnucash-dev/gitcheckouts/gnucash-clean-build/libgnucash/backend/dbi/test
"test-backend-dbi" start time: Aug 17 14:16 PDT
Output:
--
/backend/dbi/adjust sql options string localtime: OK
/backend/dbi/sqlite3/store_and_reload: test-backend-dbi:
/usr/include/boost/variant/detail/forced_return.hpp:39: T
boost::detail::variant::forced_return() [with T = const std::type_info&]:
Assertion `false' failed.

Test time =   0.73 sec
--
Test Failed.
"test-backend-dbi" end time: Aug 17 14:16 PDT
"test-backend-dbi" time elapsed: 00:00:00

I can also verify, from an earlier build, that test-import-pending-matches
is run on my system with autotools. It didn't run after the latest git pull
because of the test-backend-dbi failure in autotools as well.

That's a nice feature of the cmake route: if there is a failure in a test
subsequent tests are run whereas in autotools make check stops and if there
are other test failures you won't see them.

Regards,

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

Re: Source directory restructuring complete

[Geert Janssens]

Hi Bob,

I've been seeing this for quite some time now. Don't know where exactly it 
started. But it's definitely not local to you.

Geert

On donderdag 17 augustus 2017 13:12:34 CEST Robert Fewell wrote:
> Just built with the new structure and I see the following in the trace
> file...
> 
> * 12:03:29  WARN  Could not locate module
> gnucash/plugins/bi_import interface v.0
> * 12:03:29  CRIT  gnc_search_core_register_type: assertion
> 'typeTable' failed
> 
> The first one was easy, I had a config.user file with the load comand for
> bi_import, removed it and that one cleared, I assume that is not required
> any more.
> 
> The second comes from gnucash/gnome/top-level.c line 383 trying to register
> gnc_search_owner_new
> 
> Just wondering if other people see this or just local to me ?
> 
> Bob
> 
> On 17 August 2017 at 09:06, Geert Janssens 
> 
> wrote:
> > On donderdag 17 augustus 2017 10:02:02 CEST John Ralls wrote:
> > > Nope, the problem is at
> > > https://github.com/Gnucash/gnucash/blob/master/
> > 
> > libgnucash/engine/qof-backen
> > 
> > > d.cpp#L141:
> > >  > 
> > libgnucash/engine/qof-backe
> > 
> > > nd.cpp#L141:> /* Darwin modules can have either .so or .dylib for a
> > 
> > suffix
> > 
> > > */
> > > 
> > > if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
> > > 
> > > g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
> > > 
> > > {
> > > 
> > > auto modname = g_strdup_printf ("lib%s.dylib", module_name);
> > > g_free (fullpath);
> > > fullpath = g_build_filename (directory, modname, NULL);
> > > g_free (modname);
> > > 
> > > }
> > > auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);
> > > 
> > > follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in an
> > > autotools build and only before installation. Having directory="gnucash"
> > 
> > is
> > 
> > > correct after installation and always in a Cmake build. This will
> > 
> > probably
> > 
> > > break tests on an autotools build on Macs. I may decide I don't care and
> > > that only CMake is supported there.
> > 
> > Ah, I missed that. So the solution is simple IMO: fix the second creation
> > of
> > fullpath. Have it use absdir instead of directory. Of course that means
> > absdir
> > can only be freed after the Darwin test. I'll add push a change for you to
> > test in a minute.
> > 
> > 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: Source directory restructuring complete

[Robert Fewell]

Just built with the new structure and I see the following in the trace
file...

* 12:03:29  WARN  Could not locate module
gnucash/plugins/bi_import interface v.0
* 12:03:29  CRIT  gnc_search_core_register_type: assertion
'typeTable' failed

The first one was easy, I had a config.user file with the load comand for
bi_import, removed it and that one cleared, I assume that is not required
any more.

The second comes from gnucash/gnome/top-level.c line 383 trying to register
gnc_search_owner_new

Just wondering if other people see this or just local to me ?

Bob

On 17 August 2017 at 09:06, Geert Janssens 
wrote:

> On donderdag 17 augustus 2017 10:02:02 CEST John Ralls wrote:
> > Nope, the problem is at
> > https://github.com/Gnucash/gnucash/blob/master/
> libgnucash/engine/qof-backen
> > d.cpp#L141:
> >  libgnucash/engine/qof-backe
> > nd.cpp#L141:> /* Darwin modules can have either .so or .dylib for a
> suffix
> > */
> > if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
> > g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
> > {
> > auto modname = g_strdup_printf ("lib%s.dylib", module_name);
> > g_free (fullpath);
> > fullpath = g_build_filename (directory, modname, NULL);
> > g_free (modname);
> > }
> > auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);
> >
> > follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in an
> > autotools build and only before installation. Having directory="gnucash"
> is
> > correct after installation and always in a Cmake build. This will
> probably
> > break tests on an autotools build on Macs. I may decide I don't care and
> > that only CMake is supported there.
>
> Ah, I missed that. So the solution is simple IMO: fix the second creation
> of
> fullpath. Have it use absdir instead of directory. Of course that means
> absdir
> can only be freed after the Darwin test. I'll add push a change for you to
> test in a minute.
>
> 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: Source directory restructuring complete

[John Ralls]

> On Aug 17, 2017, at 9:37 AM, Geert Janssens  
> wrote:
> 
> On woensdag 16 augustus 2017 23:20:00 CEST John Ralls wrote:
>>> On Aug 16, 2017, at 11:12 PM, Aaron Laws  wrote:
>>> 
>>> On Wed, Aug 16, 2017 at 4:52 PM, John Ralls >> >> 
>>> wrote:
 Later, when trying to run GnuCash I found that
 libgncmod-backend-dbi.dylib
 didn't load because the directory being passed in was "dbi" instead of
 "gnucash".
 --- a/libgnucash/engine/gnc-engine.c
 +++ b/libgnucash/engine/gnc-engine.c
 @@ -74,9 +74,9 @@ gnc_engine_init_part2()
 
} libs[] =
{
 
 #if defined( HAVE_DBI_DBI_H )
 -{ "dbi", "gncmod-backend-dbi", TRUE },
 +{ "gnucash", "gncmod-backend-dbi", TRUE },
 #endif
 -{ "xml", "gncmod-backend-xml", TRUE },
 +{ "gnucash", "gncmod-backend-xml", TRUE },
 
{ NULL, FALSE }
 
}, *lib;
 
 fixes the problem and I think it will affect only Mac builds, but can
 someone check it on Linux to make sure before I commit it?
 
 Regards,
 John Ralls
>>> 
>>> This looks fine on Arch Linux building from scratch using cmake and ninja
>>> check.
>> 
>> Cool, Thanks.
>> 
> This puzzles me.
> 
> The relative directory being passed in is normally only used for an autotools 
> based build. For cmake based builds the path is automatically set to $
> {builddir}/lib/gnucash on anything but Windows, where it becomes ${builddir}/
> bin. The directory passed in should be ignored in case of a cmake based build.
> (See libgnucash/engine/qof-backend.cpp:96, function get_default_module_dir)
> 
> ISTR you are building with cmake/ninja, so how is is possible your builds are 
> affected by this relative directory ? Is your environment not setting 
> CMAKE_BUILD or is #ifdef CMAKE_BUILD false on your system ? A gcc vs clang 
> thing perhaps ?
> 
> As far as I can see I'm using the same tests and conditions as were used 
> before in gnc-engine, that's why I'm so surprised as it worked before. For a 
> comparison, the change happened in commit
> https://github.com/Gnucash/gnucash/commit/708a9a47756fb7 
> 
> 
> In any case the above change is effectively breaking the autotools build on 
> linux so we need to look further.

Nope, the problem is at 
https://github.com/Gnucash/gnucash/blob/master/libgnucash/engine/qof-backend.cpp#L141:
 

/* Darwin modules can have either .so or .dylib for a suffix */
if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
{
auto modname = g_strdup_printf ("lib%s.dylib", module_name);
g_free (fullpath);
fullpath = g_build_filename (directory, modname, NULL);
g_free (modname);
}
auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);

follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in an autotools 
build and only before installation. Having directory="gnucash" is correct after 
installation and always in a Cmake build. This will probably break tests on an 
autotools build on Macs. I may decide I don't care and that only CMake is 
supported there.

Regards,
John Ralls

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

Re: Source directory restructuring complete

[Geert Janssens]

On donderdag 17 augustus 2017 10:02:02 CEST John Ralls wrote:
> Nope, the problem is at
> https://github.com/Gnucash/gnucash/blob/master/libgnucash/engine/qof-backen
> d.cpp#L141:
>  nd.cpp#L141:> /* Darwin modules can have either .so or .dylib for a suffix
> */
> if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
> g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
> {
> auto modname = g_strdup_printf ("lib%s.dylib", module_name);
> g_free (fullpath);
> fullpath = g_build_filename (directory, modname, NULL);
> g_free (modname);
> }
> auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);
> 
> follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in an
> autotools build and only before installation. Having directory="gnucash" is
> correct after installation and always in a Cmake build. This will probably
> break tests on an autotools build on Macs. I may decide I don't care and
> that only CMake is supported there.

Ah, I missed that. So the solution is simple IMO: fix the second creation of 
fullpath. Have it use absdir instead of directory. Of course that means absdir 
can only be freed after the Darwin test. I'll add push a change for you to 
test in a minute.

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

Re: Source directory restructuring complete

[Geert Janssens]

On woensdag 16 augustus 2017 23:20:00 CEST John Ralls wrote:
> > On Aug 16, 2017, at 11:12 PM, Aaron Laws  wrote:
> > 
> > On Wed, Aug 16, 2017 at 4:52 PM, John Ralls  > >> 
> > wrote:
> >> Later, when trying to run GnuCash I found that
> >> libgncmod-backend-dbi.dylib
> >> didn't load because the directory being passed in was "dbi" instead of
> >> "gnucash".
> >> --- a/libgnucash/engine/gnc-engine.c
> >> +++ b/libgnucash/engine/gnc-engine.c
> >> @@ -74,9 +74,9 @@ gnc_engine_init_part2()
> >> 
> >> } libs[] =
> >> {
> >> 
> >> #if defined( HAVE_DBI_DBI_H )
> >> -{ "dbi", "gncmod-backend-dbi", TRUE },
> >> +{ "gnucash", "gncmod-backend-dbi", TRUE },
> >> #endif
> >> -{ "xml", "gncmod-backend-xml", TRUE },
> >> +{ "gnucash", "gncmod-backend-xml", TRUE },
> >> 
> >> { NULL, FALSE }
> >> 
> >> }, *lib;
> >> 
> >> fixes the problem and I think it will affect only Mac builds, but can
> >> someone check it on Linux to make sure before I commit it?
> >> 
> >> Regards,
> >> John Ralls
> > 
> > This looks fine on Arch Linux building from scratch using cmake and ninja
> > check.
> 
> Cool, Thanks.
> 
This puzzles me.

The relative directory being passed in is normally only used for an autotools 
based build. For cmake based builds the path is automatically set to $
{builddir}/lib/gnucash on anything but Windows, where it becomes ${builddir}/
bin. The directory passed in should be ignored in case of a cmake based build.
(See libgnucash/engine/qof-backend.cpp:96, function get_default_module_dir)

ISTR you are building with cmake/ninja, so how is is possible your builds are 
affected by this relative directory ? Is your environment not setting 
CMAKE_BUILD or is #ifdef CMAKE_BUILD false on your system ? A gcc vs clang 
thing perhaps ?

As far as I can see I'm using the same tests and conditions as were used 
before in gnc-engine, that's why I'm so surprised as it worked before. For a 
comparison, the change happened in commit
https://github.com/Gnucash/gnucash/commit/708a9a47756fb7

In any case the above change is effectively breaking the autotools build on 
linux so we need to look further.

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

Re: Source directory restructuring complete

[John Ralls]

> On Aug 16, 2017, at 11:12 PM, Aaron Laws  wrote:
> 
> On Wed, Aug 16, 2017 at 4:52 PM, John Ralls  >
> wrote:
> 
>> Later, when trying to run GnuCash I found that libgncmod-backend-dbi.dylib
>> didn't load because the directory being passed in was "dbi" instead of
>> "gnucash".
>> --- a/libgnucash/engine/gnc-engine.c
>> +++ b/libgnucash/engine/gnc-engine.c
>> @@ -74,9 +74,9 @@ gnc_engine_init_part2()
>> } libs[] =
>> {
>> #if defined( HAVE_DBI_DBI_H )
>> -{ "dbi", "gncmod-backend-dbi", TRUE },
>> +{ "gnucash", "gncmod-backend-dbi", TRUE },
>> #endif
>> -{ "xml", "gncmod-backend-xml", TRUE },
>> +{ "gnucash", "gncmod-backend-xml", TRUE },
>> { NULL, FALSE }
>> }, *lib;
>> 
>> fixes the problem and I think it will affect only Mac builds, but can
>> someone check it on Linux to make sure before I commit it?
>> 
>> Regards,
>> John Ralls
> 
> 
> 
> This looks fine on Arch Linux building from scratch using cmake and ninja
> check.

Cool, Thanks.

That's pushed along with a fix for the SQL backend memory leaks and a bad 
datetime string format passed to GncDateTime(std::string).

Regards,
John Ralls


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

Re: Source directory restructuring complete

[Aaron Laws]

On Wed, Aug 16, 2017 at 4:52 PM, John Ralls 
wrote:

> Later, when trying to run GnuCash I found that libgncmod-backend-dbi.dylib
> didn't load because the directory being passed in was "dbi" instead of
> "gnucash".
> --- a/libgnucash/engine/gnc-engine.c
> +++ b/libgnucash/engine/gnc-engine.c
> @@ -74,9 +74,9 @@ gnc_engine_init_part2()
>  } libs[] =
>  {
>  #if defined( HAVE_DBI_DBI_H )
> -{ "dbi", "gncmod-backend-dbi", TRUE },
> +{ "gnucash", "gncmod-backend-dbi", TRUE },
>  #endif
> -{ "xml", "gncmod-backend-xml", TRUE },
> +{ "gnucash", "gncmod-backend-xml", TRUE },
>  { NULL, FALSE }
>  }, *lib;
>
> fixes the problem and I think it will affect only Mac builds, but can
> someone check it on Linux to make sure before I commit it?
>
> Regards,
> John Ralls



This looks fine on Arch Linux building from scratch using cmake and ninja
check.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring complete

[John Ralls]

> On Aug 16, 2017, at 12:21 PM, John Ralls  
> wrote:
> 
>> 
>> On Aug 14, 2017, at 6:57 PM, 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.
> 
> On Mac I get a build error while compiling the standard-reports (cmake/ninja 
> build):
>  ice-9/boot-9.scm:109:20: no code for module (gnucash report standard-reports)
> 
> I fixed this temporarily by making the link by hand, but it seems that we 
> need a custom target for the copy commands at the bottom of 
> gnucash/report/standard-reports/CMakeLists.txt and the compilation of the 
> other reports there needs to be dependent on that target.

Later, when trying to run GnuCash I found that libgncmod-backend-dbi.dylib 
didn't load because the directory being passed in was "dbi" instead of 
"gnucash". 
--- a/libgnucash/engine/gnc-engine.c
+++ b/libgnucash/engine/gnc-engine.c
@@ -74,9 +74,9 @@ gnc_engine_init_part2()
 } libs[] =
 {
 #if defined( HAVE_DBI_DBI_H )
-{ "dbi", "gncmod-backend-dbi", TRUE },
+{ "gnucash", "gncmod-backend-dbi", TRUE },
 #endif
-{ "xml", "gncmod-backend-xml", TRUE },
+{ "gnucash", "gncmod-backend-xml", TRUE },
 { NULL, FALSE }
 }, *lib;

fixes the problem and I think it will affect only Mac builds, but can someone 
check it on Linux to make sure before I commit it?

Regards,
John Ralls


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

Re: Source directory restructuring complete

[Eric Theise]

On Wed, Aug 16, 2017 at 12:42 AM, Geert Janssens  wrote:

> > I now get as far as the "Making check in po" stage.
> >
> > ...
> >
> > Making check in po
> > rm -f missing notexist
> > srcdir=../../po /usr/bin/intltool-update -m
>
> All the missing file errors are the result of your build directory being a
> subdirectory of your source directory (which you can also see in the line
> above). This is a known intltool problem and has been the case before the
> restructuring already.
>

That was the organization recommended in the "Using separate build
directory" section of the wiki at https://wiki.gnucash.org/wiki/Building
I've updated that section based on your comments.


> The easiest way to avoid it currently is to make sure your build directory
> is
> outside of the source directory, for example just aside it in the same
> parent
> directory like so
> parent-dir/
> parent-dir/gnucash
> parent-dir/build
>
> Also the warnings will continue to appear until you clean up the build
> artifacts from your previous runs. From the POTFILES.in errors I deduce in
> your case that means removing (at least) the current "build" directory and
> the
> current "share" directory in your source directory.


"share" was contained within "build", FWIW.

All looks good now, thanks.

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

Re: Source directory restructuring

[Geert Janssens]

On maandag 14 augustus 2017 02:59:58 CEST Alex Aycinena wrote:
> I did a test by test comparison using Testing/Temporary/LastTest.log also
> and I find there are three tests in autotools that are missing in cmake:
> 
>  - src/engine/test/test-import-map
>  - src/engine/test/test-engine
>  - src/app-utils/test/test-app-utils
> 
> I couldn't map test # 77,
> src/import-export/test/test-import-pending-matches, to any in autotools.
> 
> Alex

Hi Alex,

I have added test-import-map and test-app-utils. On my system test-engine is 
running. Perhaps I fixed that already while restructuring the sources. I don't 
remember.

And test-import-pending matches is run via autotools on my system. It was not 
listed in the colored test output but it was run right after that. I have 
tweaked the Makefile slightly so it now is part of the colored output and 
hence more visible.

Can you verify this on your system as well ?

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

Re: Source directory restructuring complete

[John Ralls]

> On Aug 14, 2017, at 6:57 PM, 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.

On Mac I get a build error while compiling the standard-reports (cmake/ninja 
build):
  ice-9/boot-9.scm:109:20: no code for module (gnucash report standard-reports)

I fixed this temporarily by making the link by hand, but it seems that we need 
a custom target for the copy commands at the bottom of 
gnucash/report/standard-reports/CMakeLists.txt and the compilation of the other 
reports there needs to be dependent on that target.

Regards,
John Ralls


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

Re: Source directory restructuring complete

[Geert Janssens]

On woensdag 16 augustus 2017 04:37:30 CEST Eric Theise wrote:
> Thanks Geert, that worked. I live in San Francisco so the LA time zone test
> shouldn't normally pose a problem for me.
> 
Ok.

> I do wonder if there's something stronger than "make --no-print-directory
> check" that suppresses everything but the Testsuite summaries?
> 
I don't know. The extra messages never bothered me. For what it's worth, a 
cmake/ninja build will print one big test summary in the end instead of per 
directory summaries. Perhaps a cmake/make build would do that as well, but I 
never tested that combination myself.

> I now get as far as the "Making check in po" stage.
> 
> ...
> 
> Making check in po
> rm -f missing notexist
> srcdir=../../po /usr/bin/intltool-update -m

All the missing file errors are the result of your build directory being a 
subdirectory of your source directory (which you can also see in the line 
above). This is a known intltool problem and has been the case before the 
restructuring already.

The easiest way to avoid it currently is to make sure your build directory is 
outside of the source directory, for example just aside it in the same parent 
directory like so
parent-dir/
parent-dir/gnucash
parent-dir/build

Also the warnings will continue to appear until you clean up the build 
artifacts from your previous runs. From the POTFILES.in errors I deduce in 
your case that means removing (at least) the current "build" directory and the 
current "share" directory in your source directory.

Regards,

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

Re: Source directory restructuring complete

[Eric Theise]

Thanks Geert, that worked. I live in San Francisco so the LA time zone test
shouldn't normally pose a problem for me.

I do wonder if there's something stronger than "make --no-print-directory
check" that suppresses everything but the Testsuite summaries?

I now get as far as the "Making check in po" stage.

...

Making check in po
rm -f missing notexist
srcdir=../../po /usr/bin/intltool-update -m
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.

build/gnucash/gnome/gnucash.desktop.in
build/gnucash/import-export/qif-imp/qif-dialog-utils.scm
build/gnucash/import-export/qif-imp/qif-file.scm
build/gnucash/import-export/qif-imp/qif-import/qif-dialog-utils.scm
build/gnucash/import-export/qif-imp/qif-import/qif-file.scm
build/gnucash/import-export/qif-imp/qif-import/qif-merge-groups.scm
build/gnucash/import-export/qif-imp/qif-import/qif-parse.scm
build/gnucash/import-export/qif-imp/qif-import/qif-to-gnc.scm
build/gnucash/import-export/qif-imp/qif-merge-groups.scm
build/gnucash/import-export/qif-imp/qif-parse.scm
build/gnucash/import-export/qif-imp/qif-to-gnc.scm
build/gnucash/report/business-reports/aging.scm
build/gnucash/report/business-reports/balsheet-eg.eguile.scm
build/gnucash/report/business-reports/balsheet-eg.scm
build/gnucash/report/business-reports/customer-summary.scm
build/gnucash/report/business-reports/easy-invoice.scm
build/gnucash/report/business-reports/fancy-invoice.scm
build/gnucash/report/business-reports/gnucash/report/aging.scm
build/gnucash/report/business-reports/gnucash/report/balsheet-eg.scm
build/gnucash/report/business-reports/gnucash/report/customer-summary.scm
build/gnucash/report/business-reports/gnucash/report/easy-invoice.scm
build/gnucash/report/business-reports/gnucash/report/fancy-invoice.scm
build/gnucash/report/business-reports/gnucash/report/invoice.scm
build/gnucash/report/business-reports/gnucash/report/job-report.scm
build/gnucash/report/business-reports/gnucash/report/owner-report.scm
build/gnucash/report/business-reports/gnucash/report/payables.scm
build/gnucash/report/business-reports/gnucash/report/receipt.scm
build/gnucash/report/business-reports/gnucash/report/receivables.scm
build/gnucash/report/business-reports/gnucash/report/taxinvoice.scm
build/gnucash/report/business-reports/invoice.scm
build/gnucash/report/business-reports/job-report.scm
build/gnucash/report/business-reports/owner-report.scm
build/gnucash/report/business-reports/payables.scm
build/gnucash/report/business-reports/receipt.eguile.scm
build/gnucash/report/business-reports/receipt.scm
build/gnucash/report/business-reports/receivables.scm
build/gnucash/report/business-reports/taxinvoice.eguile.scm
build/gnucash/report/business-reports/taxinvoice.scm
build/gnucash/report/locale-specific/us/gnucash/report/taxtxf-de_DE.scm
build/gnucash/report/locale-specific/us/gnucash/report/taxtxf.scm
build/gnucash/report/locale-specific/us/taxtxf-de_DE.scm
build/gnucash/report/locale-specific/us/taxtxf.scm
build/gnucash/report/report-gnome/gnucash/report/report-gnome.scm
build/gnucash/report/report-gnome/report-gnome.scm
build/gnucash/report/report-system/eguile-gnc.scm
build/gnucash/report/report-system/gnucash/report/eguile-gnc.scm
build/gnucash/report/report-system/html-acct-table.scm
build/gnucash/report/report-system/html-fonts.scm
build/gnucash/report/report-system/html-style-sheet.scm
build/gnucash/report/report-system/html-utilities.scm
build/gnucash/report/report-system/options-utilities.scm
build/gnucash/report/report-system/report-utilities.scm
build/gnucash/report/report-system/report.scm
build/gnucash/report/standard-reports/account-piecharts.scm
build/gnucash/report/standard-reports/account-summary.scm
build/gnucash/report/standard-reports/advanced-portfolio.scm
build/gnucash/report/standard-reports/average-balance.scm
build/gnucash/report/standard-reports/balance-sheet.scm
build/gnucash/report/standard-reports/budget-balance-sheet.scm
build/gnucash/report/standard-reports/budget-barchart.scm
build/gnucash/report/standard-reports/budget-flow.scm
build/gnucash/report/standard-reports/budget-income-statement.scm
build/gnucash/report/standard-reports/budget.scm
build/gnucash/report/standard-reports/cash-flow.scm
build/gnucash/report/standard-reports/category-barchart.scm
build/gnucash/report/standard-reports/daily-reports.scm
build/gnucash/report/standard-reports/equity-statement.scm
build/gnucash/report/standard-reports/general-journal.scm
build/gnucash/report/standard-reports/general-ledger.scm
build/gnucash/report/standard-reports/gnucash/report/standard-reports/account-piecharts.scm
build/gnucash/report/standard-reports/gnucash/report/standard-reports/account-summary.scm
build/gnucash/report/standard-reports/gnucash/report/standard-reports/advanced-portfolio.scm

Re: Source directory restructuring complete

[Geert Janssens]

On dinsdag 15 augustus 2017 21:13:00 CEST Eric Theise wrote:
> Contents of libgnucash/engine/test/test-qof.log:
> 
> /qof/qofbook/readonly: OK
> /qof/qofbook/validate counter: OK
> /qof/qofbook/get string option: OK
> /qof/qofbook/set string option: OK
> /qof/qofbook/session not saved: OK
> /qof/qofbook/session mark saved: OK
> /qof/qofbook/get counter:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter()] No
> book!!!
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter()]
> Invalid counter name.
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter()]
> Invalid counter name. OK
> /qof/qofbook/get counter format:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter_format()]
> No book!!!
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter_format()]
> Invalid counter name.
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_get_counter_format()]
> Invalid counter name. OK
> /qof/qofbook/increment and format counter:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **:
> [qof_book_increment_and_format_counter()] No book!!!
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **:
> [qof_book_increment_and_format_counter()] Invalid counter name.
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **:
> [qof_book_increment_and_format_counter()] Invalid counter name.
> OK
> /qof/qofbook/use trading accounts: OK
> /qof/qofbook/use book-currency: OK
> /qof/qofbook/get autofreeze days: OK
> /qof/qofbook/use split action for num field: OK
> /qof/qofbook/mark session dirty: OK
> /qof/qofbook/session dirty time: OK
> /qof/qofbook/set dirty callback:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): qof.engine-WARNING **: [qof_book_set_dirty_cb()]
> Already existing callback 0x414350, will be overwritten by (nil)
> 
> OK
> /qof/qofbook/shutting down: OK
> /qof/qofbook/set get data: OK
> /qof/qofbook/get collection: OK
> /qof/qofbook/foreach collection:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: void
> qof_book_foreach_collection(const QofBook*, QofCollectionForeachCB,
> gpointer): assertion 'book' failed
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: void
> qof_book_foreach_collection(const QofBook*, QofCollectionForeachCB,
> gpointer): assertion 'cb' failed
> OK
> /qof/qofbook/set data finalizers: OK
> /qof/qofbook/mark closed: OK
> /qof/qofbook/book new and destroy: OK
> /qof/qofinstance/set get book: OK
> /qof/qofinstance/set get guid: OK
> /qof/qofinstance/instance new and destroy:
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: QofCollection*
> qof_instance_get_collection(gconstpointer): assertion
> 'QOF_IS_INSTANCE(ptr)' failed
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: gint
> qof_instance_get_editlevel(gconstpointer): assertion 'QOF_IS_INSTANCE(ptr)'
> failed
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: gboolean
> qof_instance_get_destroying(gconstpointer): assertion
> 'QOF_IS_INSTANCE(ptr)' failed
> 
> (/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.lib
> s/lt-test-qof:11950): gnc.engine-CRITICAL **: gboolean
> qof_instance_get_dirty_flag(gconstpointer): assertion
> 'QOF_IS_INSTANCE(ptr)' failed
> OK
> /qof/qofinstance/init data: OK
> /qof/qofinstance/get set slots: OK
> /qof/qofinstance/version compare: OK
> /qof/qofinstance/get set dirty: OK
> /qof/qofinstance/display name: OK
> /qof/qofinstance/begin edit: OK
> /qof/qofinstance/commit edit: OK
> /qof/qofinstance/commit edit part 2: OK
> /qof/qofinstance/instance refers to object: OK
> /qof/qofinstance/instance get referring object list from collection: OK
> /qof/qofinstance/instance get typed referring object list: OK
> /qof/qofinstance/instance get referring object list: OK
> /qof/qofobject/qof object register: OK
> /qof/qofobject/qof object lookup: OK
> /qof/qofobject/qof object get type 

Re: Source directory restructuring complete (Geert Janssens)

[Geert Janssens]

On dinsdag 15 augustus 2017 22:51:36 CEST Alex Aycinena wrote:
> On Tue, Aug 15, 2017 at 1:23 PM, Alex Aycinena 
> 
> wrote:
> > Hi Geert,
> > 
> > I did a new clone with a parallel build directory in three Fedora's and
> > had mixed results:
> > 
> > F24 - with cmake/ninja: clean ninja-build, ninja-build check, ninja-build
> > install and gnucash started OK and ran.
> > 
> > F26 VM - with autotools: clean make, make check, make install and gnucash
> > started OK and ran.
> > 
> > F25 - with autotools: clean make, make install and gnucash started OK and
> > ran. But make check failed in app-utils in test-load-module with the
> > following rather long output.
> > 
> > Regards,
> > 
> > Alex
> > 
> > output:
> > 
> > make[5]: Entering directory '/home/gnucash-dev/gitcheckouts/gnucash-new-
> > build/libgnucash/app-utils/test'
> > *** Error in `/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile':
> > double free or corruption (out): 0x01481b90 ***
> 
> 
> 
> > /home/gnucash-dev/gitcheckouts/gnucash-new/test-driver: line 107:  9549
> > Aborted (core dumped) "$@" > $log_file 2>&1
> > FAIL: test-load-module
> > PASS: test-link-module
> > PASS: test-exp-parser
> > PASS: test-scm-query-string
> > PASS: test-print-parse-amount
> > PASS: test-sx
> > PASS: test-app-utils
> 
> Geert,
> 
> On running make check a second time on the F25 it passed with no failure.
> Not sure why the difference.
> 
> Regards,
> 
> Alex

Alex,

Thanks for the feedback. I remember having encountered this a couple of times 
as well on my F25 box. And like for you it went away in a second run. As it 
seemed intermittent and deeply into the guile library I didn't investigate 
further.

Geert

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

Re: Source directory restructuring complete (Geert Janssens)

[Alex Aycinena]

On Tue, Aug 15, 2017 at 1:23 PM, Alex Aycinena 
wrote:

>
>
> Hi Geert,
>
> I did a new clone with a parallel build directory in three Fedora's and
> had mixed results:
>
> F24 - with cmake/ninja: clean ninja-build, ninja-build check, ninja-build
> install and gnucash started OK and ran.
>
> F26 VM - with autotools: clean make, make check, make install and gnucash
> started OK and ran.
>
> F25 - with autotools: clean make, make install and gnucash started OK and
> ran. But make check failed in app-utils in test-load-module with the
> following rather long output.
>
> Regards,
>
> Alex
>
> output:
>
> make[5]: Entering directory '/home/gnucash-dev/gitcheckouts/gnucash-new-
> build/libgnucash/app-utils/test'
> *** Error in `/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile':
> double free or corruption (out): 0x01481b90 ***
>
>



> /home/gnucash-dev/gitcheckouts/gnucash-new/test-driver: line 107:  9549
> Aborted (core dumped) "$@" > $log_file 2>&1
> FAIL: test-load-module
> PASS: test-link-module
> PASS: test-exp-parser
> PASS: test-scm-query-string
> PASS: test-print-parse-amount
> PASS: test-sx
> PASS: test-app-utils
>
>
Geert,

On running make check a second time on the F25 it passed with no failure.
Not sure why the difference.

Regards,

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

Re: Source directory restructuring complete (Geert Janssens)

[Alex Aycinena]

>
>
> -- Forwarded message --
> From: Geert Janssens <geert.gnuc...@kobaltwit.be>
> To: gnucash-devel@gnucash.org
> Cc:
> Bcc:
> Date: Tue, 15 Aug 2017 16:54:23 +0200
> Subject: Re: Source directory restructuring complete
> 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
>

Hi Geert,

I did a new clone with a parallel build directory in three Fedora's and had
mixed results:

F24 - with cmake/ninja: clean ninja-build, ninja-build check, ninja-build
install and gnucash started OK and ran.

F26 VM - with autotools: clean make, make check, make install and gnucash
started OK and ran.

F25 - with autotools: clean make, make install and gnucash started OK and
ran. But make check failed in app-utils in test-load-module with the
following rather long output.

Regards,

Alex

output:

make[5]: Entering directory
'/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/test'
*** Error in `/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile':
double free or corruption (out): 0x01481b90 ***
=== Backtrace: =
/lib64/libc.so.6(+0x791bb)[0x7f215a33e1bb]
/lib64/libc.so.6(+0x8282a)[0x7f215a34782a]
/lib64/libc.so.6(cfree+0x4c)[0x7f215a34b25c]
../../../libgnucash/engine/.libs/libgncmod-engine.so(_ZNSt6vectorI13GncDateFormatSaIS0_EED2Ev+0x3b)[0x7f21560d90eb]
/lib64/libc.so.6(+0x3a3d0)[0x7f215a2ff3d0]
/lib64/libc.so.6(+0x3a42a)[0x7f215a2ff42a]
/lib64/libguile-2.0.so.22(+0x58f4f)[0x7f215af64f4f]
/lib64/libguile-2.0.so.22(+0xf2696)[0x7f215affe696]
/lib64/libguile-2.0.so.22(scm_call_4+0x43)[0x7f215af6e913]
/lib64/libguile-2.0.so.22(+0x592c1)[0x7f215af652c1]
/lib64/libguile-2.0.so.22(scm_c_with_continuation_barrier+0x45)[0x7f215af653a5]
/lib64/libguile-2.0.so.22(+0xd9afc)[0x7f215afe5afc]
/lib64/libgc.so.1(GC_call_with_stack_base+0x22)[0x7f215abc5352]
/lib64/libguile-2.0.so.22(scm_with_guile+0x38)[0x7f215afe5f28]
/lib64/libguile-2.0.so.22(scm_boot_guile+0x52)[0x7f215af8c632]
/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile[0x400670]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f215a2e5401]
/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile[0x4006aa]
=== Memory map: 
0040-00401000 r-xp  fd:02 2627024
/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile
0060-00601000 r--p  fd:02 2627024
/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile
00601000-00602000 rw-p 1000 fd:02 2627024
/home/gnucash-dev/gitcheckouts/gnucash-new-build/gnc-guile
01175000-02332000 rw-p  00:00 0
[heap]
7f214400-7f2144021000 rw-p  00:00 0
7f2144021000-7f214800 ---p  00:00 0
7f2148fcb000-7f2148fcc000 rw-p  00:00 0
7f2148fcc000-7f2148fcd000 r--p  fd:02 3545232
/home/gnucash-dev/.cache/guile/ccache/2.0-LE-8-2.0/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/test/test-load-module.go
7f2148fcd000-7f2148fd r--p  fd:02 3543598
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/business-prefs.go
7f2148fd-7f2148fd7000 r--p  fd:02 3543597
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/business-options.go
7f2148fd7000-7f2148fd8000 r--p  fd:02 3543606
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/simple-obj.go
7f2148fd8000-7f2148fe6000 r--p  fd:02 3543601
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/date-utilities.go
7f2148fe6000-7f2148fe7000 r--p  fd:02 3543605
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/prefs.go
7f2148fe7000-7f2148fe8000 r--p  fd:02 3543602
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/hooks.go
7f2148fe8000-7f2148fff000 r--p  fd:02 3543604
/home/gnucash-dev/gitcheckouts/gnucash-new-build/libgnucash/app-utils/options.go
7f2148fff000-7f214fb9e000 r--p  fd:00 106949
/usr/lib/locale/locale-archive
7f214fb9e000-7f214fbad000 r--p  fd:02 3545045
/home/gnucash-dev/.cache/guile/ccache/2.0-LE-8-2.0/home/gnucash-dev/gitcheckouts/gnucash-new/libgnucash/scm/printf.scm.go
7f214fbad000-7f214fbbc000 r--p  fd:02 3545042
/home/gnucash-dev/.cache/guile/ccache/2.0-LE-8-2.0/home/gnucash-dev/gitcheckouts/gnucash-new/libgnucash/app-utils/app-utils.scm.go
7f214fbbc000-7f214fc09000 r-xp  fd:00 17078240
/opt/gnucash-git/gnucash-new/lib/libgnc-backend-xml-utils.so.0.0.0
7f214fc09000-7f214fe09000 ---p 0004d000 fd:00 17078240
/opt/gnucash-git/gnucash-new/lib/libgnc-backend-xml-utils.so.0.0.0
7f214fe09000-7f214fe0a000 r--p 0004d000 fd:00 17078240
/opt/gnucash-git/gnucash-new/lib/libgnc-backend-xml-utils.so.0.0.0
7f214fe0a000-7f214fe0e000 r

Re: Source directory restructuring complete

[Eric Theise]

Contents of libgnucash/engine/test/test-qof.log:

/qof/qofbook/readonly: OK
/qof/qofbook/validate counter: OK
/qof/qofbook/get string option: OK
/qof/qofbook/set string option: OK
/qof/qofbook/session not saved: OK
/qof/qofbook/session mark saved: OK
/qof/qofbook/get counter:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter()] No book!!!

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter()] Invalid counter name.

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter()] Invalid counter name.
OK
/qof/qofbook/get counter format:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter_format()] No book!!!

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter_format()] Invalid counter name.

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_get_counter_format()] Invalid counter name.
OK
/qof/qofbook/increment and format counter:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_increment_and_format_counter()] No book!!!

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_increment_and_format_counter()] Invalid
counter name.

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_increment_and_format_counter()] Invalid
counter name.
OK
/qof/qofbook/use trading accounts: OK
/qof/qofbook/use book-currency: OK
/qof/qofbook/get autofreeze days: OK
/qof/qofbook/use split action for num field: OK
/qof/qofbook/mark session dirty: OK
/qof/qofbook/session dirty time: OK
/qof/qofbook/set dirty callback:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
qof.engine-WARNING **: [qof_book_set_dirty_cb()] Already existing callback
0x414350, will be overwritten by (nil)

OK
/qof/qofbook/shutting down: OK
/qof/qofbook/set get data: OK
/qof/qofbook/get collection: OK
/qof/qofbook/foreach collection:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: void qof_book_foreach_collection(const QofBook*,
QofCollectionForeachCB, gpointer): assertion 'book' failed

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: void qof_book_foreach_collection(const QofBook*,
QofCollectionForeachCB, gpointer): assertion 'cb' failed
OK
/qof/qofbook/set data finalizers: OK
/qof/qofbook/mark closed: OK
/qof/qofbook/book new and destroy: OK
/qof/qofinstance/set get book: OK
/qof/qofinstance/set get guid: OK
/qof/qofinstance/instance new and destroy:
(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: QofCollection*
qof_instance_get_collection(gconstpointer): assertion
'QOF_IS_INSTANCE(ptr)' failed

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: gint qof_instance_get_editlevel(gconstpointer):
assertion 'QOF_IS_INSTANCE(ptr)' failed

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: gboolean
qof_instance_get_destroying(gconstpointer): assertion
'QOF_IS_INSTANCE(ptr)' failed

(/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test/.libs/lt-test-qof:11950):
gnc.engine-CRITICAL **: gboolean
qof_instance_get_dirty_flag(gconstpointer): assertion
'QOF_IS_INSTANCE(ptr)' failed
OK
/qof/qofinstance/init data: OK
/qof/qofinstance/get set slots: OK
/qof/qofinstance/version compare: OK
/qof/qofinstance/get set dirty: OK
/qof/qofinstance/display name: OK
/qof/qofinstance/begin edit: OK
/qof/qofinstance/commit edit: OK
/qof/qofinstance/commit edit part 2: OK
/qof/qofinstance/instance refers to object: OK
/qof/qofinstance/instance get referring object list from collection: OK
/qof/qofinstance/instance get typed referring object list: OK
/qof/qofinstance/instance get referring object list: OK
/qof/qofobject/qof object register: OK
/qof/qofobject/qof object lookup: OK
/qof/qofobject/qof object get type label: OK
/qof/qofobject/qof object printable: OK
/qof/qofobject/qof object book begin: OK
/qof/qofobject/qof object book end: OK
/qof/qofobject/qof object is dirty: OK
/qof/qofobject/qof object mark clean: OK
/qof/qofobject/qof object new instance: OK
/qof/qofobject/qof object compliance: OK

Re: Source directory restructuring complete

[Eric Theise]

Hi Geert,

Here's some output. I'm running autogen.sh + make on an Ubuntu 16.04 VM.

This is actually the first time I've been able to get gnucash to install so
I consider it a big step forward.

Eric

...
PASS: test-commodities
../../../../test-driver: line 107: 11950 Aborted (core
dumped) "$@" > $log_file 2>&1
FAIL: test-qof
PASS: test-engine

...


Testsuite summary for GnuCash 2.6.99

# TOTAL: 29
# PASS:  28
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See libgnucash/engine/test/test-suite.log
Please report to gnucash-devel@gnucash.org

Makefile:1725: recipe for target 'test-suite.log' failed
make[4]: *** [test-suite.log] Error 1
make[4]: Leaving directory
'/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test'
Makefile:1831: recipe for target 'check-TESTS' failed
make[3]: *** [check-TESTS] Error 2
make[3]: Leaving directory
'/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test'
Makefile:2100: recipe for target 'check-am' failed
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
'/home/erictheise/Repos/erictheise/gnucash/build/libgnucash/engine/test'
Makefile:535: recipe for target 'check-recursive' failed
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
'/home/erictheise/Repos/erictheise/gnucash/build/libgnucash'
Makefile:823: recipe for target 'check-recursive' failed
make: *** [check-recursive] Error 1



On Tue, Aug 15, 2017 at 7:54 AM, Geert Janssens 
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
> > > 

Re: Source directory restructuring complete

[Geert Janssens]

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

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

Re: Source directory restructuring complete

[Geert Janssens]

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
> 

> 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 

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

Source directory restructuring complete

[Geert Janssens]

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

Re: Source directory restructuring

[Alex Aycinena]

On Sun, Aug 13, 2017 at 3:52 AM, Geert Janssens 
wrote:

> On zondag 13 augustus 2017 01:34:34 CEST Alex Aycinena wrote:
> > John,
> >
> > I did a test-by-test comparison and found the following:
> >
> > in cmake but not exactly the same in autotools:
> >
> > Test  #49: scm-test-account
> > Test  #50: scm-test-create-account
> > Test  #51: scm-test-test-extra
> > Test  #52: scm-test-split
> > Test  #65: test-real-data
> > Test  #74: scm-test-load-module
> > Test  #76: test-link-generic-import
> >
> > in autotools but not in cmake:
> >
> > test-import-map
> > test-create-account (is this Test  #50:
> > scm-test-create-account?)
> > test-test-extras   (is this Test  #51:
> > scm-test-test-extra?)
> > test-account   (is this Test  #49:
> > scm-test-account?)
> > test-split (is this Test  #52:
> > scm-test-split?)
> > test-real-data.sh  (is this Test  #65:
> > test-real-data?)
> > test-load-module (for app-utils)
> > test-app-utils
> > test-link (for engine)
> > test-link (for import-export)(is this Test  #76:
> > test-link-generic-import?)
> >
> > I don't see any logs in the test subdirectories after running the tests
> > with cmake like there are under autotools which make it hard to compare
> the
> > two. Also, it would make figuring out a failure hard to do compared with
> > autotools where you do have the logs. Can this be fixed if we switch to
> > cmake or am I missing something?
> >
> > So in summary the missing tests in cmake seem to be: test-import-map
> (which,
> > by-the-way, fails randomly from time-to-time), test-load-module (for
> > app-utils), test-app-utils (which is the one that caught me), and
> test-link
> > (for engine). Not sure about the other ones or which one test #74
> > corresponds to.
>
> According to Testing/Temporary/LastTest.log, test #74 is test-load-module
> in
> app-utils. I guess we could improve the test name to reflect this.
>
> I will add test-app-utils to cmake after I finished the directory
> restructuring.
>
> Geert
>

I did a test by test comparison using Testing/Temporary/LastTest.log also
and I find there are three tests in autotools that are missing in cmake:

 - src/engine/test/test-import-map
 - src/engine/test/test-engine
 - src/app-utils/test/test-app-utils

I couldn't map test # 77,
src/import-export/test/test-import-pending-matches, to any in autotools.

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

Re: Source directory restructuring

[Geert Janssens]

On zondag 13 augustus 2017 12:52:34 CEST Geert Janssens wrote:
> On zondag 13 augustus 2017 01:34:34 CEST Alex Aycinena wrote:
> > John,
> > 
> > I did a test-by-test comparison and found the following:
> > 
> > in cmake but not exactly the same in autotools:
> > 
> > Test  #49: scm-test-account
> > Test  #50: scm-test-create-account
> > Test  #51: scm-test-test-extra
> > Test  #52: scm-test-split
> > Test  #65: test-real-data
> > Test  #74: scm-test-load-module
> > Test  #76: test-link-generic-import
> > 
> > in autotools but not in cmake:
> > 
> > test-import-map
> > test-create-account (is this Test  #50:
> > scm-test-create-account?)
> > test-test-extras   (is this Test  #51:
> > scm-test-test-extra?)
> > test-account   (is this Test  #49:
> > scm-test-account?)
> > test-split (is this Test  #52:
> > scm-test-split?)
> > test-real-data.sh  (is this Test  #65:
> > test-real-data?)
> > test-load-module (for app-utils)
> > test-app-utils
> > test-link (for engine)
> > test-link (for import-export)(is this Test  #76:
> > test-link-generic-import?)
> > 
> > I don't see any logs in the test subdirectories after running the tests
> > with cmake like there are under autotools which make it hard to compare
> > the
> > two. Also, it would make figuring out a failure hard to do compared with
> > autotools where you do have the logs. Can this be fixed if we switch to
> > cmake or am I missing something?
> > 
> > So in summary the missing tests in cmake seem to be: test-import-map
> > (which, by-the-way, fails randomly from time-to-time), test-load-module
> > (for app-utils), test-app-utils (which is the one that caught me), and
> > test-link (for engine). Not sure about the other ones or which one test
> > #74
> > corresponds to.
> 
> According to Testing/Temporary/LastTest.log, test #74 is test-load-module in
> app-utils. I guess we could improve the test name to reflect this.
> 
> I will add test-app-utils to cmake after I finished the directory
> restructuring.
> 
> Geert
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Oh, 

And I also wanted to add that dropping autotools will not be for now. We need 
to find a solution for our travis setup before we can consider that. I don't 
plan spending any time on that before the 2.8 release, so 2.8 will still 
support autotools as far as I'm concerned.

And finally, I can also confirm that intermittent failure of test-imap-
account. We have been chasing this a while back but didn't find the cause just 
yet (which I don't really like).

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

Re: Source directory restructuring

[Geert Janssens]

On zondag 13 augustus 2017 01:34:34 CEST Alex Aycinena wrote:
> John,
> 
> I did a test-by-test comparison and found the following:
> 
> in cmake but not exactly the same in autotools:
> 
> Test  #49: scm-test-account
> Test  #50: scm-test-create-account
> Test  #51: scm-test-test-extra
> Test  #52: scm-test-split
> Test  #65: test-real-data
> Test  #74: scm-test-load-module
> Test  #76: test-link-generic-import
> 
> in autotools but not in cmake:
> 
> test-import-map
> test-create-account (is this Test  #50:
> scm-test-create-account?)
> test-test-extras   (is this Test  #51:
> scm-test-test-extra?)
> test-account   (is this Test  #49:
> scm-test-account?)
> test-split (is this Test  #52:
> scm-test-split?)
> test-real-data.sh  (is this Test  #65:
> test-real-data?)
> test-load-module (for app-utils)
> test-app-utils
> test-link (for engine)
> test-link (for import-export)(is this Test  #76:
> test-link-generic-import?)
> 
> I don't see any logs in the test subdirectories after running the tests
> with cmake like there are under autotools which make it hard to compare the
> two. Also, it would make figuring out a failure hard to do compared with
> autotools where you do have the logs. Can this be fixed if we switch to
> cmake or am I missing something?
> 
> So in summary the missing tests in cmake seem to be: test-import-map (which,
> by-the-way, fails randomly from time-to-time), test-load-module (for
> app-utils), test-app-utils (which is the one that caught me), and test-link
> (for engine). Not sure about the other ones or which one test #74
> corresponds to.

According to Testing/Temporary/LastTest.log, test #74 is test-load-module in 
app-utils. I guess we could improve the test name to reflect this.

I will add test-app-utils to cmake after I finished the directory 
restructuring.

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

Re: Source directory restructuring

[John Ralls]

> On Aug 13, 2017, at 2:34 AM, Alex Aycinena <alex.aycin...@gmail.com> wrote:
> 
>> 
>> 
>> On Wed, Aug 9, 2017 at 11:54 AM, John Ralls <jra...@ceridwen.fremont.ca.us 
>> <mailto:jra...@ceridwen.fremont.ca.us>
>>> wrote:
>> 
>>> 
>>>> On Aug 9, 2017, at 9:16 PM, Alex Aycinena <alex.aycin...@gmail.com 
>>>> <mailto:alex.aycin...@gmail.com>>
>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Forwarded message --
>>>>> From: John Ralls <jra...@ceridwen.fremont.ca.us 
>>>>> <mailto:jra...@ceridwen.fremont.ca.us>>
>>>>> To: Sumit Bhardwaj <bhardw...@gmail.com <mailto:bhardw...@gmail.com>>
>>>>> Cc: gnucash-devel <gnucash-devel@gnucash.org 
>>>>> <mailto: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 
>>>>>> <mailto: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

Re: Source directory restructuring

[Alex Aycinena]

>
>
> 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
>>
>
>
John,

I did a test-by-test comparison and found the following:

in cmake but not exactly the same in autotools:

Test  #49: scm-test-account
Test  #50: scm-test-create-account
Test  #51: scm-test-test-extra
Test  #52: scm-test-split
Test  #65: test-real-data
Test  #74: scm-test-load-module
Test  #76: test

Re: Source directory restructuring

[Geert Janssens]

On zaterdag 12 augustus 2017 07:38:31 CEST John Ralls wrote:
> > On Aug 12, 2017, at 6:22 AM, Frank H. Ellenberger
> >  wrote:
> > 
> > Hi,
> > 
> > Am 08.08.2017 um 09:29 schrieb Geert Janssens:
> >> 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.
> > 
> > Ahem, if I understand them right, most tools, I am using for e.g.
> > I18N/L10N and documentation expect a directory src.
> 
> That's interesting because most Gnome packages no longer have one and yet
> they all use gettext. What tools are they? Are you sure that 'src' isn't a
> configuration directory?

I was about the ask the same question.

The current state of my work doesn't seem to have any issues. You can test it 
by pulling the 'reorganize-source-dirs' branch from my github repo 
(gjanssens). I intend to make a few more minor tweaks before pushing this to 
master.

So I'm interested to hear which tools you believe would have issues.

Thanks !

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

Re: Source directory restructuring

[John Ralls]

> On Aug 12, 2017, at 6:22 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> Am 08.08.2017 um 09:29 schrieb Geert Janssens:
>> 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.
>> 
> 
> Ahem, if I understand them right, most tools, I am using for e.g.
> I18N/L10N and documentation expect a directory src.

That's interesting because most Gnome packages no longer have one and yet they 
all use gettext. What tools are they? Are you sure that 'src' isn't a 
configuration directory?


Regards,
John Ralls

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

Re: Source directory restructuring

[Frank H. Ellenberger]

Hi,

Am 08.08.2017 um 09:29 schrieb Geert Janssens:
> 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.
> 

Ahem, if I understand them right, most tools, I am using for e.g.
I18N/L10N and documentation expect a directory src.

Regards
Frank
___
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: cmake failure (was:Re: Source directory restructuring)

[Geert Janssens]

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

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

[Aaron Laws]

On Thu, Aug 10, 2017 at 3:13 AM, Geert Janssens 
wrote:

> On donderdag 10 augustus 2017 07:08:38 CEST Sumit Bhardwaj wrote:
> > 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
>
> That's a weird error and I can't reproduce.
>
> What platform/os are you on ?
> What are the exact commands you are using to get here ?
> What's the contents of /home/bhardwajs/ac/devel/gnucash/po/missing ?
>
> Geert


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

cmake failure (was:Re: Source directory restructuring)

[Geert Janssens]

On donderdag 10 augustus 2017 07:08:38 CEST Sumit Bhardwaj wrote:
> 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

That's a weird error and I can't reproduce.

What platform/os are you on ?
What are the exact commands you are using to get here ?
What's the contents of /home/bhardwajs/ac/devel/gnucash/po/missing ?

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

[John Ralls]

> 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

Re: Source directory restructuring

[Alex Aycinena]

>
>
>
> -- 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.

Regards,

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

Re: Source directory restructuring

[John Ralls]

> On Aug 9, 2017, at 8:02 PM, Geert Janssens  wrote:
> 
> On woensdag 9 augustus 2017 18:51:52 CEST Geert Janssens wrote:
>>> 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.
>> 
>> Which dist target rough edges are you referring to here ?
>> 
>> I know there is the issue I can't add Makefile.in files to the dist tarball
>> (because Rob's dist rules prevent my cmake version from running the
>> necessary commands). Other than that the dist tarball generated via both
>> build systems are identical on my system after I ironed out a few minor
>> issues last month. Since we're right now discussing dropping autotools,
>> this very issue becomes moot.
>> 
>> Do you know other ones ?
> 
> Oh, and there is this little detail called Travis... Perhaps I should first 
> test whether it can switch to cmake or not.

I did when I was testing it but now I've forgotten. Having the tarball have 
both systems configs and makefiles and so on was certainly one of them, and 
you're right that it's moot when we drop autotools.

I'm sure that Travis can do cmake, but not sure that it can do a new enough 
cmake: We need at least 3.0 and 3.2 or later is preferred. ISTR that Travis has 
only 2.8.

Regards,
John Ralls



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

Re: Source directory restructuring

[Geert Janssens]

On woensdag 9 augustus 2017 18:51:52 CEST Geert Janssens wrote:
> > 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.
> 
> Which dist target rough edges are you referring to here ?
> 
> I know there is the issue I can't add Makefile.in files to the dist tarball
> (because Rob's dist rules prevent my cmake version from running the
> necessary commands). Other than that the dist tarball generated via both
> build systems are identical on my system after I ironed out a few minor
> issues last month. Since we're right now discussing dropping autotools,
> this very issue becomes moot.
> 
> Do you know other ones ?

Oh, and there is this little detail called Travis... Perhaps I should first 
test whether it can switch to cmake or not.

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

Re: Source directory restructuring

[Geert Janssens]

On dinsdag 8 augustus 2017 19:01:44 CEST John Ralls wrote:
> > On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  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.
 
Which dist target rough edges are you referring to here ?

I know there is the issue I can't add Makefile.in files to the dist tarball 
(because Rob's dist rules prevent my cmake version from running the necessary 
commands). Other than that the dist tarball generated via both build systems 
are identical on my system after I ironed out a few minor issues last month. 
Since we're right now discussing dropping autotools, this very issue becomes 
moot.

Do you know other ones ?

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

Re: Source directory restructuring

[Aaron Laws]

On Mon, Aug 7, 2017 at 7:56 AM, Geert Janssens 
wrote:

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

I echo the other sentiments: This will make it much easier to grok and
contribute to gnucash.

Concerning cutecash, "It's not maintained" may be the case now, but I
remember working on some libqof changes before and having to "maintain"
cutecash since it was breaking because of the changes. It was a bit
irritating. If it's a difficult thing to bring yourself to, perhaps you
could have a friend pull the trigger? ;-)

Thanks for thinking through this and putting it on paper. I look forward to
seeing the fruit of this labour.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[John Ralls]

> On Aug 8, 2017, at 5:50 PM, Sumit Bhardwaj  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


___
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: Source directory restructuring

[John Ralls]

> 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 as well until we're ready to split them 
> up. 
> My work on the csv importer is an important step in the right direction. For 
> the next major cycle I hope to continue this for the other importers and 
> exporters as well.
> 
>> Gtk+ is very much Gnome and depends on other pieces of the Gnome project.
>> The actual name of the directory isn't really important so we can call it
>> gtk if you'd rather, but there are lots of other Gnome project dependencies
>> that aren't going away as long as we're using Gtk+. Remember that in
>> addition to gnome, gnome-util, and 

Re: Source directory restructuring

[Geert Janssens]

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 as well until we're ready to split them up. 
My work on the csv importer is an important step in the right direction. For 
the next major cycle I hope to continue this for the other importers and 
exporters as well.

> Gtk+ is very much Gnome and depends on other pieces of the Gnome project.
> The actual name of the directory isn't really important so we can call it
> gtk if you'd rather, but there are lots of other Gnome project dependencies
> that aren't going away as long as we're using Gtk+. Remember that in
> addition to gnome, gnome-util, and gnome-query there's also register-gnome,
> report-gnome, and (until your latest changes) business-gnome. There's also
> Gtk+ code in import-export, html, and probably a few other places that
> don't immediately come to mind. Setting that aside we still 

Re: Source directory restructuring

[John Ralls]

> On Aug 7, 2017, at 2:56 PM, Geert Janssens  wrote:
> 
> 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,

These are to be top-level directories, so the current src goes away, right? The 
rest assumes that to be the case.

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.

I want to get rid of gnc-module too, but it's not easy.

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?

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.

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.

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.

Reports might 

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

Re: Source directory restructuring

[Derek Atkins]

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

Source directory restructuring

[Geert Janssens]

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