[GNC-dev] Gnucash 2.6: make distcheck in po bombs on file paths starting with sub
John Ralls
jralls at ceridwen.us
Mon Jun 15 12:30:36 EDT 2020
> On Jun 14, 2020, at 11:29 PM, Kevin Buckley <kevin.m.buckley at gmail.com> wrote:
>
> On Mon, 15 Jun 2020 at 02:31, John Ralls <jralls at ceridwen.us> wrote:
>>
>> Building 2.6.21a works fine for me on Ubuntu 18.04 with automake 1.15.1. None of the source files are copied into gnucash-2.6.21/_build/sub, so there's no POTFILE.skip issue.
>>
>> I did have to make two changes to get it to build from the dist tarball: Remove line 23 (src/plugins/example/gnc-plugin.example.c) from po/POTFILES.skip and add test-date-utilities.scm to EXTRA_DIST at line 69 of src/app-utils/test/Makefile.am
>>
>> Since you've presumably made changes and tagged for a new distribution, I suggest you first make sure that you can build 2.6.21a with the changes above. If it doesn't work I suggest first trying automake 1.15.1. Once you have 2.6.21a building successfully then reapply your changes and see if they break anything.
>>
>> I'm a bit concerned that since you're running distcheck with a new tag you're planning to distribute it to others and to create the expectation that we will support it. We won't, so please don't.
>
> To answer the last bit first, rest assured I have no plans to distribute
> this work. Never my intention to do anything with it, other than use it
> myself, though perhaps aluding to the fact that something might be
> possible.
>
> To be honest I doubt anyone else but me would be interested
> in using the 2.6 series.
>
> The tagging is just a way to allow me to compare changes
> easily. I noticed there was a 2.6.99 floating around in the
> official sources. I myself have used 2.6.31, 42 and 51, at
> various stages of playing around, but as I coalesced around
> "the next step using the 2.6.21 sources pretty much unmodified",
> 2.6.22 seemed "right".
>
> I'd like to see how far I could take the 2.6 environment and
> backport updates into it.
>
> The idea behind moving into the new source layout was simply
> that it would make it easier to see what had been changed.
>
> Having said that, I have no intention of using a DB backend,
> nor building against Boost, or with CMake, for that matter.
>
> I note that there are a few places in the last 2.6 code release
> where it says "won't fix because we're moving to CMake" and
> felt that was a bit of a cop-out, but that's just a personal thing,
> not a criticism.
>
> I would like to try and get my 2.6 stuff compiling within a CMake
> system whilst maintaining a working Autotools build system,
> although I'd always build against the latter.
>
> Most of that will have been done for 2.7 onwards anyway, so
> it should just be a matter of matching up the newer files that
> already exist.
>
> I realy feel that I'm merely re-arranging what the GnuCash
> developers have done, not actually adding anything
>
> Onto the more techincal side of things though,
>
> The reason for running "distcheck" was that I read something
> that suggested that was the best test of the code, although, as
> I mentioned, I had been doing a make dist and then a separate
> unpack and build as a test anyway. Clearly the make distcheck
> has thrown up issues I might have missed, even if they do appear
> to be specific to my environment.
>
>
> i did get the 2.6.21a source, or something close (haven't got my
> work dir to hand but I started with the commit commented as "Fix
> Typo") that was two or three after 2.6.21 was tagged) building as
> was, however, that was before I'd found the "trust make distcheck",
> so yes I will go back and try that against the old layout.
>
> I'm building on a Ubuntu 14 OS (as I loathe SystemD and of course,
> the init system is of little consequence in building non-OS software)
> but I have, as I said, added enough /usr/local tools to be a bit more
> up-to-date (ha-ha!) for the purpose of .
>
> I really should have moved to using LinuxFromScratch system in
> everyday use by now but, what can I tell you, I'm not quite there
> yet, Gnucash is one of the missing pieces, so UB14/CentOS610 it is.
>
> Finally, at the risk of overstating things, I really do appreciate you taking
> a look into this. From the first time I came across Gnucash, I was amazed
> at the way it merged the C and Scheme parts and, even though I've not
> really used anything that required that specific knowledge, it's been a useful
> insight to have had.
I somehow missed this admonition in my earlier reply and failed to add the list back as a copy-to, so rectifying it here:
All replies need to copy the list.
Look, we're done with 2.6 and we're done with autotools. That's why there were "won't fix" autotools bugs. Not a cop-out, there's no point in fixing something that isn't used any more.
All that distcheck does is unpack the distribution tarball and build and check the result, then clean up. That ensures that everything needed to build and pass the test suite is included in the tarball and that everything that's supposed to be removed with make clean is in fact removed. It doesn't do anything about code quality.
It certainly should build on stock Ubunutu 14.04, so move your upgraded tools out of the path and build. That should work. Then add the upgraded tools back in one at a time until it fails. At that point you can decide whether to stick with the older tool or try to fix the build to use the newer one. You'll probably learn more about autotools than you ever wanted to know in the process and might come to realize why we've decided cmake is much better.
Regards,
John Ralls
More information about the gnucash-devel
mailing list