From mboxrd@z Thu Jan 1 00:00:00 1970 To: weigelt@metux.de, 9fans@9fans.net Subject: Re: [9fans] Modularizing plan9port From: "Russ Cox" Date: Wed, 11 Jun 2008 06:30:48 -0700 In-Reply-To: <20080611124038.GA3004@nibiru.local> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20080611132853.E4B821E8C1F@holo.morphisms.net> Topicbox-Message-UUID: ba9c40e6-ead3-11e9-9d60-3106f5b1d025 > 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