On Tue, Mar 15, 2011 at 06:04:13AM +0100, Stefan Bodewig wrote:
> I've seen you've already sold your soul to buildbot 8-)
And it feels good!
> > Would it be acceptable to provide a patch for RAT which changes this
> > behavior to work on paths?
>
> Sure.
I'm still willing to take a crack at this if it would be useful. I wonder,
though -- is RAT intended for use outside the context of the ASF? The
Buildbot solution works for us, as it does for Subversion, another C project
-- and it seems that the Ant and Maven interfaces work for numerous ASF Java
projects. Does Buildbot obviate the need for a CLI interface?
> > A couple different approaches are possible.
>
> > * Modify the interface for -e/--exclude
> > * Introduce a new command line flag.
>
> Unless you manage to implement the first one in a way that it still
> works the same for all old command line invocations (or all reasonable
> uses) I'd prefer the second. -E may be good.
If we wanted to modify -e while attempting to preserve back compat, we could
apply the filter twice: once against the file and once against the path.
Leading wildcards present a few corner cases that could spoil such plans,
though. The following filter would have failed to match a file named ".txt"
before, but it could start matching now:
*.txt # doesn't match against ".txt" but matches against "foo/.txt"
A potentially greater annoyance is documenting the behavior of the modified
flag. Explaining the behavior of the following filter would be difficult:
api.c # matches against both "api.c" and "foo/api.c".
I'm not sure that quirk makes a lot of sense in the context of directory
filters.
Thus I don't think it would be wise to modify -e/--exclude unless breaking back
compat is acceptable. Since it's not, the only option is to create another
flag.
Marvin Humphrey
