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

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

Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5


From: Miles Bader
Subject: Re: [Gnu-arch-users] preparing to stress test tla with linux-2.5
Date: Sun, 24 Aug 2003 18:53:57 -0400
User-agent: Mutt/1.3.28i

On Sun, Aug 24, 2003 at 03:24:09PM -0700, Tom Lord wrote:
>  And to the list of people to whom I should, in some sense, be advocating
> breaking the kernel up into a multi-project config.

Hmmm, while I appreciate that often its nice to compose source trees from
multiple sources, I currently think of configs as an `extra layer of
annoyance' and since I'm quite used to treating the kernel as as a single big
tree, cringe a bit at having to use configs for it.

No doubt this is partly my ignorance about configs (really I have only used
them to get Tom's source tree for tla set up).

I guess my main beef is the way they seem to interfere with the nice `single
command operates on/produces a single tree' property of arch/tla, and that I
to stop and think about the fact that `OH, in _this_ tree (or part of a tree)
I have to use special commands because it uses configs.'  Really I want tla
to do all my thinking for me when that's possible.  With a config'd tree,
even just checking out the tree seems a multi-step process: first checkout
the `wrapper dir' [for projects that have one], then find what config I want
and use `build-config' [for which it's even a pain to use shell completion
because the argument to `build-config' _isn't_ a filename, but rather has an
implicit `configs/' prepended to it].

If I want to do an update / diff / whatever, the config boundaries can
similarly intrude (this isn't really true with tla though, since I only care
about the one src/tla subtree).

In the case of the kernel, there are natural boundaries for organizational
splits -- e.g., the various arch/ subdirs -- but existing development styles
definitely treat it all as `one big tree', and it's not uncommon for single
changes to pervasively affect the whole tree, regardless of organizational
boundaries.

So, I'm not sure what my real point is other than (1) configs currently seem
annoyingly clunky, and (2) it's not clear that in their current form they
really fit with existing kernel development style.

Comments?

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)




reply via email to

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