[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: config(5) break down
On Fri, Mar 26, 2010 at 05:39:03PM +0700, Robert Elz wrote:
> Date: Fri, 26 Mar 2010 14:52:09 +0900
> From: Masao Uebayashi <uebayasi%gmail.com@localhost>
> | You need to include dependency. You don't need to care the order of
> | include lines. This is pretty much same as C headers including its
> | dependency vs. not include in *.h but managing the order in *.c.
> But C include files are a disaster - a huge mess inherited from history.
> No-one sane would deliberately design that as a solution for anything.
> As a user of the things I'd much rather all that just happened automatically,
> when I use fopen() if the compiler needs stdio.h, it should just go and
> get stdio.h - it's absurd to make me explicitly say I need it.
> For C, because of the nature of the world 30+ years ago, and development
> since, there's nothing we can do about it. But copying that as if it was
> a great system would be absurd.
We all know implications and limitations of "include" conventions.
> | Same as pkgsrc "buildlink3.mk" including its dependency too.
> No, those are totally different - those are different files because
> they're managed separately, as a part of each package - the maintainer
> of graphics/jpeg looks after jpeg/builink3.mk and makes it does whatever
> is necessary to correctly link whatever -ljpeg required. Those are
> separate files, not because separate files is a good thing, but because
> the management of anything different would be a nightmare.
> If your reason for lots of little conf files was because there are lots of
> little independent projects, each producing and looking after their own
> little piece of the puzzle, that would be something that might reach
> agreement (if it were correct).
> But the reason seems to just be this dependency ordering thing - which it
> looks like you're planning on solving it the .h file way (with each file
> including anything it needs, then added protection against including anything
> more than once, and ... which is all just a huge mess).
> That's not the way to fix this problem. If it has become serious enough that
> doing it manually is no longer sensible, then just fix config to remove the
> ordering rule - I don't think there's any good reason for it (and you
> are not proposing making it stronger). Making config do a two pass parse of
> the config file(s) would be an afternoon's work - it was never done that way
> because manual ordering started out being so simple to do, that the
> work was never justified. Then, as each new entry was added, manually
> ordering that new entry was always less than that afternoon's work. Almost
> certainly the sum of all of that effort is (now) greater than the effort it
> would have taken to fix config, but no-one has ever really fallen against
> it hard enough that they could justify spending the afternoon to fix it.
> Maybe that's changed now - certainly I suspect that there's been more time
> spent on this discussion than it would take to have just fixed config in the
> first place.
> | Having a
> | single *.conf per module is natural. As natural as userland commands
> | and libraries have a single Makefile for each.
> This one is a different argument (and as I remember this is more where
> you started, before you got onto that ordering nonsense), this relates more
> to management, and is much more reasonable.
This is almost same thing as modularity.
> However, since I'm a believer in the single module kernel, that also makes
> me a believer in the single files.conf file - and for people like me,
> following this line of reasoning, you'd agree right? (Regardless of whether
> or not you agree with the single module approach).
Are you a believer in the single netbsd.c, yes?
Complaining the number of possible split config files is as pointless as
complaining the number of *.c files in src/sys. The reason why we'll end up
with thousands (not millions) of *.conf is that the netbsd kernel is composed
of thousands of components.
If your real complainment is about putting build procedure / module dependency
in a separate file, you should consider to propose merging bin/*/Makefile
My long term goal is to make ~everything in src/sys modules, without digging
sys/modules/*. Without scattering build a single procedure of ehci(4) across
sys/conf/files and sys/dev/usb.
> I'm pretty sure he understands the existing syntax. I am pretty sure that
> I understand the existing syntax as well. The syntax of what is in the
> file(s) is pretty much an orthagonal issue - I certainly agree that the
> syntax could be improved, but I don't see that having almost any bearing
> upon the multiple files issue - it doesn't need to change to allow a 2 pass
> parser to remove any ordering relationship on the config file lines,
> and it can change, whether we have one config file (as it once was), a dozen
> or whatever it is now, or a hundred or more (your proposal).
> When mrg said he wanted to cry, or laugh, at your message, I suspect it
> was because if there had been a zillion little files, the weekend you spent
> would probably have been at least a week....
Obviously you haven't wasted enough time to learn config(5).
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
Main Index |
Thread Index |