Re: [9fans] Plan9 development

[Bakul Shah <bakul+plan9@bitblocks.com>]

On Thu, 04 Nov 2010 22:20:04 -0000 Charles Forsyth <forsyth@terzarima.net>  wrote:
> >But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfil
> e and acid)
> >at least as long as all that Java in the ant distribution (213151 lines)?
> >That's a lot of catching up to do.
> >The market has clearly spoken, and it appears that more lines dominates the
> soup.
>
> one interesting thing about that example is that if it were done again
> for the Plan 9 environment, mk might well be even smaller, since
> some of the existing functionality isn't really used,
> or might be achieved by simpler mechanisms, or with functionality
> added instead by further composition with other programs;
> alternatively, it might be redone in a radically different way.
>
> either way you probably wouldn't get an entire O'Reilly book out of it though.

Some random thoughts triggered by Charles'es message:

1.  The idea is to map mk to a special filesystem -- "mkfs"
    takes on a whole new meaning! One would overlay mkfs on
    a source tree.

    We are going to build foo
	mkdir foo foo/src
	<put foo's source files in foo/src/>
	cd foo

    Specify a build rule for command foo:
	echo 8c src/*.c -o .build > .rule

    Specify dependencies a b & c of foo:
	ln -s ../^(a b c) .dep/

    Build foo:
	ls .build
    This checks dependencies a b c (if they are directories,
    checks a/.build etc) and builds them.  This will need to
    be fleshed out the most... Default rules can be added
    with something like plumb....

    Install foo:
	cp .build /bin/foo

    Remove temporary files
	rm .obj/* .build

    I used symlinks to point to dependencies but may be there
    is a smarter way.

    A default .rule can be derived depending on what is in src/

    Initial .dep/ may be derived by mkfs running a dependency
    deriving program.

    Objects in .obj/ may be similarly derived.

    The utility if any is that a small set of mechanisms is
    used, coupled with a simple convention.

    This was fun little exercise (spent more time on
    writing this email) so I am sure there are lots of holes.
    Probably not worth building.  It'd be too slow.

2.  Factor out a way to track changes in any fs and trigger
    commands.  This would probably obviate the need to build a
    number of special purpose file systems.