Re: [9fans] Modularizing plan9port

["Russ Cox" <rsc@swtch.com>]

> I'm going to modularize plan9port a bit.
>
> Ideally, each component (library, app, etc) should become it's
> completely own package.

I fail to see what is ideal about this.

Ask yourself whether you're doing this because it would
actually make your life easier or because of some
pre-conceived notion that software packaging should
be complex.

> So I intent do write some script which creates Makefile's from
> mkfile's and maybe even does some build-time configuration
> (sort of ./configure ;-)). That script(s) could be packet along
> with some other fundamental p9p build utils, and this package
> then would be the very first in depedency chain. Taking cross-
> builds into account, this would be an TOOL or HOST dependency,
> since it runs on the building host, not the target - an compiler-
> less target wouldn't ever need it (it plays in the same liga as
> tools like lex, make, autoconf, etc).
>
> What do you think about this approach ?

I think you are wasting your time.

There's no need to fiddle with the build structure:
you could still require the whole tree to build things
and then just split up the post-build tree.
Then you don't have to worry about rewriting Makefiles
or adding your own configure scripts or other horrors.
I certainly won't take any of that back into the main tree.

If you just want to create a package for the Linux du jour,
just build the tree and then make it one big package.
If that would be too large a package, you could reasonably
split it into four:

	28/12	font	$PLAN9/font
	68/27	bin 	$PLAN9/bin and $PLAN9/lib/lib*.a
	20/4 	src 	$PLAN9/src
	18/6 	base	everything else

The numbers are MB, uncompressed and compressed.
Splitting out bin/lib makes it easy to swap in binaries for
a different architecture.  Splitting out src (or font) makes
those files easy to drop if you need to scrimp on disk space.
There's not much point to anything more fine-grained.

Russ