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 
> To: gnucash-devel 
> 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: Fw: VAT Call for Software developers

[Mike or Penny Novack]

Uh ... Putting my "business analyst" hat on I see nothing there which 
says WHAT data needs to be transmitted to them digitally.


This discussion has seemed to be making the assumption that gnucash 
would need to be sending it's "books" to them digitally which is NOT the 
same thing as saying that some reports, filings, etc. must be sent to 
them digitally << perhaps they get exported and then something else 
sends them >>


For example here I might do an electronic FILING using data produced by 
gnucash to supply the numbers that get filled in during the electronic 
filing process. But gnucash is not doing the electronic filing.


I think, before involving coding developers we need that information so 
that "business" level developers can determine what the REQUIREMENTS are.


Michael D Novack

PS: In my working days, sometimes wore one of those hats and sometimes 
the other.




On 8/17/2017 8:47 AM, Mike Evans wrote:

I just received this from HMRC.

Begin forwarded message:

Date: Thu, 17 Aug 2017 10:46:57 +
From: 
To: 
Subject: VAT Call for Software developers


Dear All,

I writing to tell you about a conference call that has been arranged for 
11:00am on 05 September 2017.

You may be aware that the Government has proposed that businesses with a 
turnover above the VAT threshold (currently £85,000) will be mandated to keep 
digital records and submit data to HMRC through its secure API platform 
service. The changes will take place from April 2019 for VAT.

Current plans are to make the APIs available for private beta test in October 
2017 and we want to advise interested software vendors about our thinking as 
well as provide them with an early opportunity to raise any issues or 
questions. It will of course also help us identify if your company is 
considering developing or enhancing a VAT product to support the proposals.
We can then arrange to work with you going forward, providing the usual 
technical assistance and other support needed to prepare for the pilot, from 
April 18 and  in readiness for the changes being mandated from April 2019.

   *   Only businesses with a turnover above the VAT threshold will have to 
keep digital records and only for VAT purposes. They will only need to do so 
from 2019.
   *   Other businesses will be able to file digitally on a voluntary basis for 
both VAT and Income Tax and NICs

Our current development schedule is as follows

   1.  October 2017 - private beta (API testing) with interested software 
vendors
   2.  April 2018 - public beta (pilot) data submission for VAT purposes (MVP 
to include unincorporated businesses); we will be inviting business volunteers 
throughout the year, anticipating that early adopters will already be using 
software and therefore likely to already be your customers. These will include 
both Tax Agents, their clients as well as unrepresented VAT businesses.
   3.  From April 2019 - data submission for VAT purposes (that is all 
VAT-registered businesses whether the business is unincorporated or not); 
Mandated for VAT registered businesses with a turnover above the VAT threshold, 
but all VAT registered businesses can use the service.

Please let me know if you intend to join the call so I can make the necessary 
arrangements. Please send your reply to this email no later than 17:00 on  24th 
August 2017.


Kind Regards

Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - Software 
Developers Collaboration -  Software Developers Support Team (SDST) | 2nd 
Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 8AA

The information in this e-mail and any attachments is confidential and may be 
subject to legal professional privilege. Unless you are the intended recipient 
or his/her representative you are not authorised to, and must not, read, copy, 
distribute, use or retain this message or any part of it. If you are not the 
intended recipient, please notify the sender immediately.

HM Revenue & Customs computer systems will be monitored and communications 
carried on them recorded, to secure the effective operation of the system and for 
lawful purposes.

The Commissioners for HM Revenue and Customs are not liable for any personal 
views of the sender.

This e-mail may have been intercepted and its information altered.


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



--
There is no possibility of social justice on a dead planet except the equality 
of the grave.

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

Re: VAT Call for Software developers

[Adonay Felipe Nogueira]

If this is about the "Making Tax, Digital", and if someone is able to
attend such meeting, please note what I mentioned in:
[[https://lists.gnucash.org/pipermail/gnucash-user/2017-August/071844.html]].

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: [[https://libreplanet.org/wiki/User:Adfeno#vCard]]
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: VAT Call for Software developers

[John Ralls]

> On Aug 17, 2017, at 2:47 PM, Mike Evans  wrote:
> 
> I just received this from HMRC.
> 
> Begin forwarded message:
> 
> Date: Thu, 17 Aug 2017 10:46:57 +
> From: 
> To: 
> Subject: VAT Call for Software developers
> 
> 
> Dear All,
> 
> I writing to tell you about a conference call that has been arranged for 
> 11:00am on 05 September 2017.
> 
> You may be aware that the Government has proposed that businesses with a 
> turnover above the VAT threshold (currently £85,000) will be mandated to keep 
> digital records and submit data to HMRC through its secure API platform 
> service. The changes will take place from April 2019 for VAT.
> 
> Current plans are to make the APIs available for private beta test in October 
> 2017 and we want to advise interested software vendors about our thinking as 
> well as provide them with an early opportunity to raise any issues or 
> questions. It will of course also help us identify if your company is 
> considering developing or enhancing a VAT product to support the proposals.
> We can then arrange to work with you going forward, providing the usual 
> technical assistance and other support needed to prepare for the pilot, from 
> April 18 and  in readiness for the changes being mandated from April 2019.
> 
>  *   Only businesses with a turnover above the VAT threshold will have to 
> keep digital records and only for VAT purposes. They will only need to do so 
> from 2019.
>  *   Other businesses will be able to file digitally on a voluntary basis for 
> both VAT and Income Tax and NICs
> 
> Our current development schedule is as follows
> 
>  1.  October 2017 - private beta (API testing) with interested software 
> vendors
>  2.  April 2018 - public beta (pilot) data submission for VAT purposes (MVP 
> to include unincorporated businesses); we will be inviting business 
> volunteers throughout the year, anticipating that early adopters will already 
> be using software and therefore likely to already be your customers. These 
> will include both Tax Agents, their clients as well as unrepresented VAT 
> businesses.
>  3.  From April 2019 - data submission for VAT purposes (that is all 
> VAT-registered businesses whether the business is unincorporated or not); 
> Mandated for VAT registered businesses with a turnover above the VAT 
> threshold, but all VAT registered businesses can use the service.
> 
> Please let me know if you intend to join the call so I can make the necessary 
> arrangements. Please send your reply to this email no later than 17:00 on  
> 24th August 2017.
> 
> 
> Kind Regards
> 
> Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - Software 
> Developers Collaboration -  Software Developers Support Team (SDST) | 2nd 
> Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 8AA
> 
> The information in this e-mail and any attachments is confidential and may be 
> subject to legal professional privilege. Unless you are the intended 
> recipient or his/her representative you are not authorised to, and must not, 
> read, copy, distribute, use or retain this message or any part of it. If you 
> are not the intended recipient, please notify the sender immediately.
> 
> HM Revenue & Customs computer systems will be monitored and communications 
> carried on them recorded, to secure the effective operation of the system and 
> for lawful purposes.
> 
> The Commissioners for HM Revenue and Customs are not liable for any personal 
> views of the sender. 

Mike,

Can you attend the conference call and raise the issue about per-application 
secret keys that we've discussed here? I'd do it but I'll be back in California 
by then and I'm seldom compos mentis at 3AM.

Regards,
John Ralls

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

Fw: VAT Call for Software developers

[Mike Evans]

I just received this from HMRC.

Begin forwarded message:

Date: Thu, 17 Aug 2017 10:46:57 +
From: 
To: 
Subject: VAT Call for Software developers


Dear All,

I writing to tell you about a conference call that has been arranged for 
11:00am on 05 September 2017.

You may be aware that the Government has proposed that businesses with a 
turnover above the VAT threshold (currently £85,000) will be mandated to keep 
digital records and submit data to HMRC through its secure API platform 
service. The changes will take place from April 2019 for VAT.

Current plans are to make the APIs available for private beta test in October 
2017 and we want to advise interested software vendors about our thinking as 
well as provide them with an early opportunity to raise any issues or 
questions. It will of course also help us identify if your company is 
considering developing or enhancing a VAT product to support the proposals.
We can then arrange to work with you going forward, providing the usual 
technical assistance and other support needed to prepare for the pilot, from 
April 18 and  in readiness for the changes being mandated from April 2019.

  *   Only businesses with a turnover above the VAT threshold will have to keep 
digital records and only for VAT purposes. They will only need to do so from 
2019.
  *   Other businesses will be able to file digitally on a voluntary basis for 
both VAT and Income Tax and NICs

Our current development schedule is as follows

  1.  October 2017 - private beta (API testing) with interested software vendors
  2.  April 2018 - public beta (pilot) data submission for VAT purposes (MVP to 
include unincorporated businesses); we will be inviting business volunteers 
throughout the year, anticipating that early adopters will already be using 
software and therefore likely to already be your customers. These will include 
both Tax Agents, their clients as well as unrepresented VAT businesses.
  3.  From April 2019 - data submission for VAT purposes (that is all 
VAT-registered businesses whether the business is unincorporated or not); 
Mandated for VAT registered businesses with a turnover above the VAT threshold, 
but all VAT registered businesses can use the service.

Please let me know if you intend to join the call so I can make the necessary 
arrangements. Please send your reply to this email no later than 17:00 on  24th 
August 2017.


Kind Regards

Dennis Dawkins |Senior Delivery Operations Lead| HMRC CDIO Digital - Software 
Developers Collaboration -  Software Developers Support Team (SDST) | 2nd 
Floor, Accounts Office Shipley, Victoria Street, Shipley BD98 8AA

The information in this e-mail and any attachments is confidential and may be 
subject to legal professional privilege. Unless you are the intended recipient 
or his/her representative you are not authorised to, and must not, read, copy, 
distribute, use or retain this message or any part of it. If you are not the 
intended recipient, please notify the sender immediately.

HM Revenue & Customs computer systems will be monitored and communications 
carried on them recorded, to secure the effective operation of the system and 
for lawful purposes.

The Commissioners for HM Revenue and Customs are not liable for any personal 
views of the sender. 

This e-mail may have been intercepted and its information altered.
   Dear All,


   I writing to tell you about a conference call that has been arranged
   for 11:00am on 05 September 2017.


   You may be aware that the Government has proposed that businesses with
   a turnover above the VAT threshold (currently £85,000) will be mandated
   to keep digital records and submit data to HMRC through its secure API
   platform service. The changes will take place from April 2019 for VAT.


   Current plans are to make the APIs available for private beta test in
   October 2017 and we want to advise interested software vendors about
   our thinking as well as provide them with an early opportunity to raise
   any issues or questions. It will of course also help us identify if
   your company is considering developing or enhancing a VAT product to
   support the proposals.

   We can then arrange to work with you going forward, providing the usual
   technical assistance and other support needed to prepare for the pilot,
   from April 18 and  in readiness for the changes being mandated from
   April 2019.
 * Only businesses with a turnover above the VAT threshold will have
   to keep digital records and only for VAT purposes. They will only
   need to do so from 2019.
 * Other businesses will be able to file digitally on a voluntary
   basis for both VAT and Income Tax and NICs


   Our current development schedule is as follows
1. October 2017 – private beta (API testing) with interested software
   vendors
2. April 2018 – public beta (pilot) data submission for VAT purposes
   (MVP 

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