bug-gnulib
[Top][All Lists]
Advanced

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

Re: maint.mk syntax check problems


From: Simon Josefsson
Subject: Re: maint.mk syntax check problems
Date: Wed, 14 Sep 2011 19:16:09 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)

Martin von Gagern <address@hidden> writes:

> Re-sending for the mailing list, forgot that a moment ago.
>
> On 14.09.2011 16:49, Simon Josefsson wrote:
>> I'm not a fan of separate shell scripts, each new file to deal with
>> seems to incur a small maintainance cost over time -- consider when they
>> are renamed or moved.  I think gnulib already install a large number of
>> of files into projects using gnulib, so we should be conservative about
>> increasing that number needlessly.
>
> You could integrate vc-list-files into that file as a function, thus
> keeping the number of files the same. Would have the added benefit that
> the result of the listing could be cached in a bash array, making my own
> caching from https://github.com/gagern/gnulib/commit/40533f3fa4b9 obsolete.
>
> I guess you could also turn this into a perl script instead of a bash
> script, but while that would allow integration of the existing perl
> scripts useless-if-before-free, announce-gen and update-copyright, and
> would make some regexp checks easier, it would mean rewriting the checks
> considerably. Some checks would probably be less readable than their
> shell equivalent. And perhaps some projects might be using one of the
> existing perl scripts independently from maint.mk.
>
>> In general I'm in favor of as simple code as possible, but I think here
>> the cost with many new shell scripts outweigh the benefit of improved
>> code.
>
> Just to make certain there is no misunderstanding: I'm thinking about a
> single file containing all these scripts as functions, not multiple
> files with one test each, as your answer might possibly suggest.

Then I'm mildly in favor of your approach -- having one more script is
not that cumbersome, and would probably make it easier to write some
more advanced tests.  However, I'm not sure it makes sense to rewrite
currently working tests, so I would support using a new script for tests
not already written or when maintaining existing tests becomes too
burdensome due to makefile escaping complexity.

However, I think Jim's opinion here should have the most weight...

/Simon



reply via email to

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