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

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

Re: [Gnu-arch-users] Re: tagline robustness


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

Zack Brown wrote:
> On Thu, Aug 28, 2003 at 06:36:50AM -0700, Robert Anderson wrote:
> > On Thu, 2003-08-28 at 03:45, Maksim Lin wrote:
> > > Exactly.
> > > Software (even scm) should be making life as easy as possible for users 
> > > not harder.
> > 
> > Easier over the next 5 minutes, the next 5 months, or the next 5 years? 
> > That's the issue, and it's not a simple one ("just make life easier").
> 
> People seem to be talking around the issue. Exactly what restrictions on
> directory tree structure are we talking about here? Could someone please
> post some examples?

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,
so many commands fail (including what-changed) if you don't clean up the
tree first. The result is that tla strongly encourages building outside
the tree (or in a precious-tagged directory in the tree, like tla's
=build). Note that this can be overcome, especially when the tagging-
method changes go in.

This was one of my early gripes about tla (larch behaved differently),
but now that I've transitioned my few projects to an out-of-source
build process, it doesn't bother me. This is one of the things I'm
thinking about when I say that (some of) arch's restrictions lead to
better software, but it's initially painful. And as Miles pointed out,
it's much more of a hassle for pre-existing projects.

Another restriction is the set of characters allowed in filenames. Lots
of people don't like this, although I don't recall seeing a practical
problem being observed yet.

The use of multi-tree projects isn't a restriction, but it's been
advocated as a solution to the (soon to be addessed) problem of arch's
speed on huge projects like the linux kernel. It's a good idea in
general, as it promotes modularity, but it may not be appropriate for
all large projects.

I believe all of these issues will become moot points in the
not-too-distant future, but they sometimes present difficulties in the
early stages of a project. We'll see what other items people come up
with.

Jason




reply via email to

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