> 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
