gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] Re: tagline robustness


From: Jason McCarty
Subject: [Gnu-arch-users] Re: tagline robustness
Date: Thu, 28 Aug 2003 22:14:38 -0400
User-agent: Mutt/1.5.4i

Miles Bader wrote:
> Jason McCarty <address@hidden> writes:
> > Projects that build inside the source tree can be problematic with tla.
> > With explicit or tagline tagging, all the .o files are considered
> > unrecognized, and other generated files are treated as untagged
> > source,
> 
> Can't you just add .o + the binary names (&c) to the =tagging-method
> regexps?  Currently you'll have problems if you need such names to be
> specific to particular subdirectories, but I gather the more powerful
> system that can deal with that is already in some yet-uncommitted branch
> somewhere.

Yes, that's true. But you might not be able to overcome the problems if
you have generated files of the same type as non-generated files (think
parser-generators), unless you want to enumerate every single special-
case file in the regexps. And tagline won't work in that situation
because there will be duplicated tags. The only current way to avoid
this in general is to "make clean" before doing anything, or building in
a separate dir. Once the tagging-method changes are in place, you can
take the lazy (and potentially dangerous) way out and specify
    source .*
    explicit-tag
    untagged-source precious
in =tagging-method. Then all the untagged files will be left alone and
not considered as an error by tla. Of course, just building in a build
dir is cleaner, so that's what I ended up doing (it's a small project).

> CVS and other systems have exactly the same issue except that they
> usually complain rather than falling over (and this stuff should be
> tweaked in arch).
> 
> You wouldn't notice this issue with most projects because they've
> already got well-tuned .cvsignore files; as someone suggested, once the
> new more-powerful regexps are in, a simple script could automatically
> generate them from existing .cvsignore files.
> 
> > so many commands fail (including what-changed) if you don't clean up the
> > tree first.
> 
> I agree this aspect should be cleaned up a bit, but I think it's a
> matter of slight tweaking rather than a wholesale change in attitude.

Yep. 

Jason




reply via email to

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