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 <uebay...@gmail.com> > Message-ID: <70f62c5e1003252252h6e5ba506xfafceb76f854b...@mail.gmail.com> > > | 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 > certainly > 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 > afternoon's > 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 into bin/*/*.c. 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 -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635