Re: config(5) break down

["Wojciech A. Koszek" <wkoszek%FreeBSD.org@localhost>]

On Thu, Mar 11, 2010 at 07:31:58PM +0000, David Holland 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.

[..]

> 
> 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:
> 
>    file ufs/mfs/mfs_miniroot.c
> 
>    module UFS {
>       option UFS_DIRHASH {
>          flag opt_ffs.h
>          file ufs/ufs/ufs_dirhash.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
>       }
>    }

The FreeBSD config(8) unsuprisingly suffers from the same problems. Syntax
presented above makes sense. In FreeBSD, we can also override per-file
compiler's flag, but files with custom compiler settings tend to come from the
same group.

Even though I don't like the idea of recursively embedded stuff, I think that:

        group X {
                require "Y";
                require "Z";

                file a.c
                file b.c
        }

Could work and make syntax a bit clearer. Anyway, this could even be more fully
featured:

        group X {
                require "Y";
                require "Z";

                if (option("X_DEBUG")) {
                        file "X_debug.c";
                }
        }

I picked "group", since I believe there'd be a demand on decreasing kernel
build time for developers. So:

        device  X

builds device X staticly into the kernel (and maybe does something
device-specific), while:

        module  X

Only builds a KLD. I picked "module", since it seems to be more-or-less an 
oposite of:

        static  X

which could build feature "X", which is not a device" staticly. I think your
config(8) has this problem solved somehow, since you seem to have "filesystem"
keyword as well.  Nowadays, given that as you mentioned for NetBSD, in FreeBSD
we also have no scoping for config(8), we must build all KLDs just in case
someone needs them, since we don't know which file belongs to which module.

This could also let us to have one parser for files.*, options.* and kernel
configuration files, like GENERIC.

I was wondering how does Linux/Solaris kernel build system work in terms of
opt_*.h files?  Do they have some alternative solutions for #ifdef's based on
what has been included into the kernel at configuration time?

-- 
Wojciech A. Koszek
wkoszek%FreeBSD.org@localhost
http://FreeBSD.czest.pl/~wkoszek/