Source directory restructuring

[John Ralls]

> On Aug 13, 2017, at 2:34 AM, Alex Aycinena <alex.aycinena at gmail.com> wrote:
> 
>> 
>> 
>> On Wed, Aug 9, 2017 at 11:54 AM, John Ralls <jralls at ceridwen.fremont.ca.us <mailto:jralls at ceridwen.fremont.ca.us>
>>> wrote:
>> 
>>> 
>>>> On Aug 9, 2017, at 9:16 PM, Alex Aycinena <alex.aycinena at gmail.com <mailto:alex.aycinena at gmail.com>>
>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ---------- Forwarded message ----------
>>>>> From: John Ralls <jralls at ceridwen.fremont.ca.us <mailto:jralls at ceridwen.fremont.ca.us>>
>>>>> To: Sumit Bhardwaj <bhardwajs at gmail.com <mailto:bhardwajs at gmail.com>>
>>>>> Cc: gnucash-devel <gnucash-devel at gnucash.org <mailto:gnucash-devel at 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 <bhardwajs at gmail.com <mailto:bhardwajs at 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 <args> srcdir && make && make check && make install or
>>> (quite a
>>>>> bit faster) cmake -G Ninja <args> 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 at 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-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.
> 
> By the way, Sumit mentioned recently that he had found one of Geert's
> e-mails in the Spam folder in gmail so I looked and sure enough I also had
> three from you and one from Geert in my Spam folder. Not sure why since I
> have corresponded to both of you from time to time for several years. The
> banner at the top says it is in Spam because "it is in violation of
> Google's recommended email sender guidelines", whatever that may mean.

Alex,

Thanks for doing the audit. What was the difference that you found between cmake and autotools for the seven tests that were "not exactly the same"?

The test output in cmake goes to a single file,  ${topbuilddir}/Testing/Temporary/LastTest.log.

As for the spam, IIRC GMail provides a "whitelist". Perhaps if you add your known correspondents to it you'll get fewer false positives. Most spam filters these days also work by training a per-user Bayesian database, and that depends on not only marking new spam email that isn't filtered but also reviewing the filtered email periodically (I do it  once a week) and marking false positives as "not spam".

Regards,
John Ralls