groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Automake migration proposal


From: Bertrand Garrigues
Subject: Re: [Groff] Automake migration proposal
Date: Wed, 13 Aug 2014 08:24:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hello,

On Tue, Aug 12 2014 at 08:02:31 AM, Werner LEMBERG <address@hidden> wrote:
>> Now how do we proceed?  I guess the problems found so far should be
>> fixed in the automake branch in any case.  
Ingo,

Yes, I will work on these problems in the next few days. Thanks for your
tests!

>> However, what i found is merely what i inadvertently bumped into.
>> There are no doubt more bugs, and bugs like the one below are *very*
>> hard to find in a code audit of a 150 thousand line diff.  So who is
>> really sure the diff is of sufficient quality to merge it?  I am
>> certainly not, and the three subtle bugs i ran into without even
>> starting a real audit do not make me any more confident.

Well, it was probably a bit optimistic to think that the automake branch
could be merged into the master quickly ... Werner suggested to make a
new release on the master branch, and in the mean time we should take
time to do more tests.

To test my work, beside checking the usuall 'make', 'make clean', 'make
distchek', I usually do a 'make install', and compare the results with
the main branch (using 2 trees with DESTDIR option). Quite a long task
because this means comparing some generated scripts that should differ
only by 1 line where the date is inserted. In the last few weeks, I've
worked mainly on dist, distcheck and check, only quickly comparing both
installation trees (basically checking that no file was missing).

I think I need to list much more precisely the tests that I have done
with their results, and which one I haven't (like building without the
doc) in a file. Alternatively, I could put this description in bug
report.

> Well, your suggestion of splitting the patch into smaller units is the
> way to go, I reckon.  In case it improves legibility, I don't mind if
> there is a series of commits that don't compile – simply tag them as
> such in the commit message.

Werner,

I'm not sure if it would be easy to split the patch, you could not
really check the intermediate states if you can't compile. I think the
easiest way to review the build system is the compare every .am file
with the original Makefile.sub. Some .am have simple automake rules, the
most difficult .am are the one with custom install rules (but most of
these custom rules were directly adapted from the Makefile.sub).

Regards,

--
Bertrand Garrigues



reply via email to

[Prev in Thread] Current Thread [Next in Thread]