On Fri, Mar 12, 2010 at 4:31 AM, David Holland <dholland-t...@netbsd.org> wrote: > On Mon, Mar 08, 2010 at 06:33:04PM +0900, Masao Uebayashi wrote: > > > Well, first of all nothing says you can't read the whole file before > > > resolving dependencies; there's nothing inherently wrong with > > > > > > define foo: bar > > > : > > > define bar: baz > > > : > > > > > > I have no idea if config currently allows this but it's not exactly > > > difficult to arrange. > > > > I don't think it's worth. > > Well, maybe. It seems like one of the things you're concerned about is > the maintenance overhead of making sure everything in "files" appears > in the right order. If you make it order-independent that goes away, > and "files" can be sorted by some more meaningful criteria. > > That seems like generally a good idea. > > > Split *.conf files can be also distributed with *.[ch]. Its notation is > > self-descriptive. The only problem I'm aware of is it consumes more disk > > space. > > That and it becomes harder to find what you're looking for, which is I > guess what I'm mostly concerned about. It's already somewhat of a pain > to find any particular declaration in the various files.* files. > > I think there are two reasonable ways to arrange it and we ought to > pick one and then hack on config itself until it works acceptably that > way. > > These are: > > (1) one big file, or as close to it as we can reasonably manage given > that we have all these different ports with different stuff; > > (2) one file per source directory, like makefiles in a traditional > project. > > The Linux folks after much pain and suffering finally settled on the > second way; however, their kernel build system uses recursive make > invocations so the structure all matches up. > > The way the world works in NetBSD I tend to think one big file is > better. I'd even maybe argue that we should drop files.$(ARCH) in > favor of syntax, maybe something like > > if (ARCH == i386) { > file arch/i386/i386/autoconf.c > : > } > > but perhaps not. > > Still, I don't think one file per module (which given modular drivers > will tend to end up being one files.*/*.conf file per *.c file in many > parts of the tree) is a good idea. > > > > No, it seems like you're intending to use whole files to define groups > > > instead of braces or some other punctuation. There is no need to split > > > things into separate files just to show grouping. > > > > True. > > config already seems to use braces for declaring bus locators (or > something like that, probably not quite the right terminology) -- what > grouping syntax should we use? (Of course, the braces could be changed > if necessary; I count 579 uses but that's not really a major > massediting task.) > > > > (Besides, it's not necessarily as flat as all that, either.) > > > > 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). > file ufs/mfs/mfs_miniroot.c > > module UFS { > option UFS_DIRHASH { > flag opt_ffs.h > file ufs/ufs/ufs_dirhash.c > } > > option QUOTA { > flag commandline > file ufs/ufs/ufs_quota.c > } > > file ufs/ufs/ufs_ihash.c > file ufs/ufs/ufs_inode.c > file ufs/ufs/ufs_lookup.c > file ufs/ufs/ufs_bmap.c > file ufs/ufs/ufs_vfsops.c > file ufs/ufs/ufs_vnops.c > > file ufs/ffs/ffs_alloc.c > file ufs/ffs/ffs_balloc.c > file ufs/ffs/ffs_inode.c > file ufs/ffs/ffs_snapshot.c > file ufs/ffs/ffs_subr.c > file ufs/ffs/ffs_tables.c > file ufs/ffs/ffs_vfsops.c > file ufs/ffs/ffs_vnops.c > > module FFS : filesystem { > option FFS_NO_SNAPSHOT { > flag opt_ffs.h > } > option FFS_EI { > flag opt_ffs.h > file ufs/ffs/ffs_bswap.c > } > option APPLE_UFS { > flag opt_ffs.h > file ufs/ffs/ffs_appleufs.c > } > option UFS_EXTATTR { > flag opt_ffs.h > option UFS_EXTATTR_AUTOSTART { > flag opt_ffs.h > } > file ufs/ufs/ufs_extattr.c > } > ifoption WAPBL { > file ufs/ufs/ufs_wapbl.c > file ufs/ffs/ffs_wapbl.c > } > module MFS : filesystem { > file ufs/mfs/mfs_vfsops.c > file ufs/mfs/mfs_vnops.c > } > } > > module EXT2FS : filesystem { > file ufs/ext2fs/ext2fs_alloc.c > file ufs/ext2fs/ext2fs_balloc.c > file ufs/ext2fs/ext2fs_bmap.c > file ufs/ext2fs/ext2fs_bswap.c > file ufs/ext2fs/ext2fs_inode.c > file ufs/ext2fs/ext2fs_lookup.c > file ufs/ext2fs/ext2fs_readwrite.c > file ufs/ext2fs/ext2fs_subr.c > file ufs/ext2fs/ext2fs_vfsops.c > file ufs/ext2fs/ext2fs_vnops.c > } > > module LFS : filesystem { > option LFS_KERNEL_RFW { > flag opt_lfs.h > file ufs/lfs/lfs_rfw.c > } > file ufs/lfs/lfs_alloc.c > file ufs/lfs/lfs_balloc.c > file ufs/lfs/lfs_bio.c > file ufs/lfs/lfs_cksum.c > file ufs/lfs/lfs_debug.c > file ufs/lfs/lfs_inode.c > file ufs/lfs/lfs_itimes.c > file ufs/lfs/lfs_segment.c > file ufs/lfs/lfs_subr.c > file ufs/lfs/lfs_syscalls.c > file ufs/lfs/lfs_vfsops.c > file ufs/lfs/lfs_vnops.c > } > } In this plan, what *.kmod will be generated? > I'm not sure why most of the ffs sources are currently declared "ffs | > lfs | mfs | ext2fs", but I haven't changed that. > > Also note that QUOTA is currently not defflag'd (!) - I haven't > changed that either, although it seems like a bug. > > > > I thought you said all you needed to do was grep for the logical > > > operators... > > > > I said it's possible. > > > > Again, I don't want to change config(1) at all. And I don't need. > > Well... changing it would probably be helpful. Ultimately we want the > right balance of changing config(1) and rearranging its input files. > > I'm perfectly happy to rework the parser to support syntax like the > above if we can all agree on what it should be. So you're proposing a syntax change without understanding the existing syntax? (You don't know what braces are for, you didn't know "define" behavior, ...) I have to say that your proposal is not convincing to me... Masao