automake-patches
[Top][All Lists]
Advanced

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

Re: Proposal: dirlist.d/ directory support


From: Ralf Wildenhues
Subject: Re: Proposal: dirlist.d/ directory support
Date: Thu, 24 Aug 2006 08:58:16 +0200
User-agent: Mutt/1.5.12 (2006-08-10)

* Robert Schiele wrote on Wed, Aug 23, 2006 at 10:04:48PM CEST:
> On Wed, Aug 23, 2006 at 08:20:41PM +0200, Ralf Wildenhues wrote:
> 
> > [...] what's missing from the patch before it
> > can be applied is a ChangeLog entry, an addition to the "For example"
> > part in the documentation right after your patch hunk would be nice, a
> > testsuite addition to make sure the feature works as intended,

> I can provide all that stuff, given that someone tells me about the rules (if
> there are any) on how to name the testcases and/or whether it is ok to extend
> the existing one for the dirlist feature or whether a completely new one is
> prefered.

General rules are in the file HACKING (in the CVS tree), ChangeLog
entries and whatnot are described in the Gnu Coding Standards, probably
a tests/dirlist3.test would be the simplest (you can copy off
dirlist2.test), and I guess you may want to add m4/dirlist.d/...

* Robert Schiele wrote on Wed, Aug 23, 2006 at 11:12:43PM CEST:
> On Wed, Aug 23, 2006 at 01:48:57PM -0700, Ben Pfaff wrote:
> > 
> > Debian's run-parts tool, that runs all of the scripts in a
> > particular directory, limits the files that it runs to those
> > whose names consist entirely of upper and lower case letters,
> > digits, underscores, and hyphens.

> I have no strong opinion on whether this is desired or not.  Thus if
> this idea is generally accepted, I could easily add such a check.

I like the general idea, but am a bit unsure whether it's preferable to
just use a suffix and skip files with a leading dot; unfortunately,
*.dirlist does not fit 8.3 (do we still need that?).  The rules Ben
outlined would be fine with me, too.  Anyway, I'm not good at inventing
interfaces, and the documentation update would seem to be more work than
the implementation in any case. 

Cheers,
Ralf




reply via email to

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