Created attachment 513408 [details] gtest-1.8.0-r1.ebuild app-office/gnucash-2.7.3 not only unconditionally requires dev-cpp/gtest, but some source files as well. The attached ebuild meets this requirement.
Created attachment 513848 [details, diff] gnucash-2.7.3-no-gtest-src.patch (In reply to Aaron W. Swenson from comment #0) > Created attachment 513408 [details] > gtest-1.8.0-r1.ebuild > > app-office/gnucash-2.7.3 not only unconditionally requires dev-cpp/gtest, > but some source files as well. > > The attached ebuild meets this requirement. It seems that gnucash-2.7.3 unnecessarily tries to build gtest/gmock. Assuming that eautoreconf is still being run in `src_prepare` and '>=dev-cpp/gtest-1.8.0' is a hard dependency, this patch should work. Please test and let me know.
Using the patch and running the tests, one test fails for me, test-qof. The following snippet is from "${S}/libgnucash/engine/test/test-qof.log": > /qof/gnc-date/qof print date dmy buff: There are some differences between > distros in the way they namelocales, and this can cause trouble with the > locale-basedformatting. If you get the assert in this function, run locale > -aand make sure that en_US, en_GB, and fr_FR are installed and thatif a suffix > is needed it's in the suffixes array.** > ERROR:test-gnc-date.c:493:test_gnc_setlocale: code should not be reached > FAIL test-qof (exit status: 134)
(In reply to Peter Levine from comment #2) > Using the patch and running the tests, one test fails for me, test-qof. > The following snippet is from "${S}/libgnucash/engine/test/test-qof.log": > > > /qof/gnc-date/qof print date dmy buff: There are some differences between > > distros in the way they namelocales, and this can cause trouble with the > > locale-basedformatting. If you get the assert in this function, run locale > > -aand make sure that en_US, en_GB, and fr_FR are installed and thatif a suffix > > is needed it's in the suffixes array.** > > ERROR:test-gnc-date.c:493:test_gnc_setlocale: code should not be reached > > FAIL test-qof (exit status: 134) So, this test is known to fail if en_US, en_GB and fr_FR aren't all installed and upstream is fine with that, I guess. See http://gnucash.1415818.n4.nabble.com/Source-directory-restructuring-complete-td4693265.html#a4693294. Running with MAKEOPTS="-j4 --keep-going" shows 2 more testcase failures, test-userdata-dir and test-userdata-dir-invalid-home. I'll see if I can figure those out. They seem to be related to files created in "${HOME}"/.local/share, and the same testcases don't fail when running `make check` outside of the portage environment. Manually creating those directories in src__test doesn't seem to make a difference, though. Also note that for the src_install phase of gnucash-2.7.3, there is a MAKEOPTS bug that causes failure for me with the message "/usr/bin/ld: cannot find -lgnc-backend-xml-utils". It's fixed by changing 'gnome2_src_install' to 'MAKEOPTS=-j1 gnome2_src_install'.
(In reply to Peter Levine from comment #1) > Created attachment 513848 [details, diff] [details, diff] > gnucash-2.7.3-no-gtest-src.patch > > It seems that gnucash-2.7.3 unnecessarily tries to build gtest/gmock. > Assuming that eautoreconf is still being run in `src_prepare` and > '>=dev-cpp/gtest-1.8.0' is a hard dependency, this patch should work. > Please test and let me know. Ya know, I looked at that and I couldn't see the problem. This patch fixes it. Thank you! Would you submit it upstream[1]? The neighboring CMakeLists.txt needs similar changes, as well. [1]: https://github.com/Gnucash/gnucash
I'm reassigning this following the resolution. Leaving Peter in CC since he's written the patches. Feel free to re-CC proxy-maint if anything needs to be committed in gtest itself.
I brought this (In reply to Aaron W. Swenson from comment #4) > Would you submit it upstream[1]? The neighboring CMakeLists.txt needs > similar changes, as well. > > [1]: https://github.com/Gnucash/gnucash I responded to an issue pertaining to this bug on the gnucash-devel mailinglist. From https://lists.gnucash.org/pipermail/gnucash-devel/2018-January/041412.html: > I do have a question for the Gentoo folks, though: The Googletest documentation > recommends *against* building googletest as a shared library [1]. I get that it > means that googletest doesn’t really fit in the Linux distro’s standard model, > but it seems a bit over the top to deliberately break building googletest as > part of the project being tested given googletest’s usage guidelines. > > So two questions back: Why not make an exception for Googletest? Why, if Gentoo > is willing to patch Googletest to prevent projects from using it as recommended > is Gentoo not willing to also patch those projects to comply with their policy? > > Regards, > John Ralls > > [1] https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal <https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-is-it-not-recommended-to-install-a-pre-compiled-copy-of-google-test-for-example-into-usrlocal> It is true that Googletest suggests not installing pre-compiled libraries. The reasons they give don't exactly mesh with Gentoo's philosophy in that each user should be responsible for not using ridiculous CXXFLAGS and LDFLAGS and the argument that they give for ODR violations at link time is a bandaid over the issue (one of which was just fixed with https://github.com/gentoo/gentoo/commit/b6ff87f01454fa2c2525917e7d2ff2b0089ade02#diff-34666df03bb2cb2f78eb00d3f3ec328a). However, building gtest/gmock from the same sources as those used for the built libraries wouldn't necessarily be bundling if the libraries aren't reinstalled with another package, just built for src_test. And many reasons given against bundling as listed in https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies don't really apply to such a scenario. So maybe it would it be best to patch it as originally requested.
(In reply to Peter Levine from comment #6) > So maybe it would it be best to patch it as originally requested. It's apparently a no go. I'm going to submit a patch to gnucash eventually but there is no guarantee it will be accepted.
(In reply to Peter Levine from comment #7) > (In reply to Peter Levine from comment #6) > > So maybe it would it be best to patch it as originally requested. > > It's apparently a no go. I'm going to submit a patch to gnucash eventually > but there is no guarantee it will be accepted. I've included the patch in the 2.7.3 ebuild. I'll commit it when the news item reaches maturity. [1] If we do need to include the sources at some point, we should be able to easily add it to the gnucash ebuild. [1]: https://archives.gentoo.org/gentoo-dev/message/6bf2cbce3664a5e3a11ec3608a19a4ef
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0924e0af0e078bcca0a38df4b628acd7eb0a0b7e commit 0924e0af0e078bcca0a38df4b628acd7eb0a0b7e Author: Aaron W. Swenson <titanofold@gentoo.org> AuthorDate: 2018-02-23 11:25:56 +0000 Commit: Aaron W. Swenson <titanofold@gentoo.org> CommitDate: 2018-02-23 11:25:56 +0000 app-office/gnucash: Small cleanup Closes: https://bugs.gentoo.org/643566 Closes: https://bugs.gentoo.org/627010 Closes: https://bugs.gentoo.org/639786 Package-Manager: Portage-2.3.19, Repoman-2.3.6 app-office/gnucash/Manifest | 2 - .../gnucash/files/gnucash-2.7.3-no-gtest-src.patch | 15 -- app-office/gnucash/gnucash-2.6.15-r1.ebuild | 111 --------------- app-office/gnucash/gnucash-2.6.15.ebuild | 112 --------------- app-office/gnucash/gnucash-2.7.3.ebuild | 153 -------------------- app-office/gnucash/gnucash-2.7.4.ebuild | 155 --------------------- 6 files changed, 548 deletions(-)
