On Thu, Mar 25, 2010 at 12:46:10PM +0900, Masao Uebayashi wrote: > > ?> > ?> It's necessary to be flat to be modular. > > ?> > > > ?> > Mm... not strictly. That's only true when there are diamonds in the > > ?> > dependency graph; otherwise, declaring B inside A just indicates that > > ?> > B depends on A. Consider the following hackup of files.ufs: > > ?> > > ?> There're diamonds (for example, ppp-deflate depends on ppp and zlib). > > > > Sure. But mostly there aren't. > > % grep ':.*,' sys/conf/files | wc -l > 86
And? I don't understand your point. There are a lot more than 86 entities in sys/conf/files. > > ?> In this plan, what *.kmod will be generated? > > > > The ones declared? Or one big one, or one per source file, or whatever > > the blazes you want, actually... > > And how dependencies are represented? In files.*? In the example I wrote before, either explicitly or by containment. If you mean in the modules themselves, that seems like a different problem. > > Um. I know perfectly well that config currently uses braces for > > something else. That's irrelevant. There's no need to use braces for > > grouping; it just happens to be readily comprehensible to passersby. > > There's an infinite number of possible other grouping symbols that can > > be used, ranging from << >> to (! !) or even things like *( )*. > > Furthermore, the existing use of braces can just as easily be changed > > to something else if that seems desirable. > > I don't like unnecessary changes. And I don't like making a mess in order to avoid "unnecessary" changes. Do it right, then it won't have to be done again next year. > > There's a reason I said "syntax like the above" and "if we can all > > agree on what it should be". That wasn't a concrete proposal, it > > wasn't meant to be a concrete proposal, no concrete proposal is > > complete without an analysis of whether the grammar remains > > unambiguous, and nitpicking it on those grounds is futile. > > > > You seem to be completely missing the point. > > So you're objecting my concrete proposal with your not-concrete > proposal. All you've said is "I don't like small files". If you have > a concrete proposal, please post it as another thread. I've objected to your "concrete" proposal, which wasn't very concrete, on the grounds that I don't see any advantages to exploding files.* into a million tiny pieces. I am trying to suggest alternate approaches. -- David A. Holland dholl...@netbsd.org