bug-inetutils
[Top][All Lists]
Advanced

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

[bug-inetutils] Re: ANNOUNCE: Daily snapshot and autobuild service


From: Simon Josefsson
Subject: [bug-inetutils] Re: ANNOUNCE: Daily snapshot and autobuild service
Date: Thu, 12 Apr 2007 10:26:28 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux)

"Alfred M. Szmidt" <address@hidden> writes:

>    Thanks.  Ok to install m4/autobuild.m4 too?
>
> In acinclude.m4 please.

Patch installed.

>    >    >    Any objections to installing the patch?
>    >    >
>    >    > My only objection is that m4/ shouldn't be used for this
>    >    > macro, the macro should be put in acinclude.m4 instead.
>    >
>    >    acinclude.m4 is deprecated according to the Automake manual:
>    >
>    > Oh, I didn't know that.  That sucks, and I vehemently disagree with
>    > the stated reasons as well.  But on the bright side, it doesn't sound
>    > as if it is deprecated, just discouraged.  Do you know if the autoconf
>    > maintainers have any plans on actually removing support for
>    > acinclude.m4?
>
>    I haven't seen any such plans, but given that many projects still have
>    a acinclude.m4 I doubt it will be soon.  Still, I think GNU projects
>    should follow the best-practices set by other GNU projects if
>    feasible.
>
> I disagree that splitting it into several small files is `best'
> practise though.  If you have only a few macros as we do, having them
> in one spot is better than putting some odd 14 files in m4/ for each
> macro or something equally silly.

My experience is that having many macros in acinclude.m4 makes it more
difficult to diff and update the macro from its upstream source,
leading to neglected updates of the code.  For example, Inetutils
acinclude.m4 contains an old version of the jm_INCLUDED_REGEX macro
(serial 12) compared to the regexp.m4 in gnulib (serial 46).

Come to think of it, perhaps it would be easier to make a gnulib
module out of autobuild.m4...  That would solve the update problem.
Yes, I'll suggest that on the gnulib list.

/Simon




reply via email to

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