From: Enrico Weigelt <weigelt@metux.de>
To: 9fans@9fans.net
Subject: Re: [9fans] Modularizing plan9port
Date: Wed, 11 Jun 2008 17:30:20 +0200 [thread overview]
Message-ID: <20080611153020.GE402@nibiru.local> (raw)
In-Reply-To: <20080611132853.E4B821E8C1F@holo.morphisms.net>
* Russ Cox <rsc@swtch.com> wrote:
Hi,
> Ask yourself whether you're doing this because it would
> actually make your life easier or because of some
It *does* make my life easier!
I'm not just using it for personal stuff, but for lots of highly
customized production systems, where careful maintenance is
very important.
Disk space is not the issue, but the amount of code to be
maintained (source and binary). So the target systems *always*
should only contain exactly what's needed - nothing more.
> pre-conceived notion that software packaging should be complex.
Actually, I want to make it simpler. You probably can't see this
since you don't know what happens behind the scenes at my site ;-P
One essential constraint is, that everything's built through an
sysroot'ed cross-toolchain. Right after compile several checks
run on the output, packages are then trimmed-down (eg. removing
all build-time stuff) and then it goes to the testing system.
Only after the whole pipe ran through properly, the binary
package is committed to the production systems.
> 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.
The current approach already fails with crosscompiling.
I *can not* use the in-tree built mk for further building
and I *must* make sure that imports are strictly coming
from within sysroot.
> 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.
You shouldn't generally declare this approach as horror,
just because autoconf is a horrible example.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
next prev parent reply other threads:[~2008-06-11 15:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 12:40 Enrico Weigelt
2008-06-11 12:47 ` erik quanstrom
2008-06-11 13:05 ` Jeff Sickel
2008-06-11 13:30 ` Russ Cox
2008-06-11 15:30 ` Enrico Weigelt [this message]
2008-06-11 15:43 ` Uriel
2008-06-11 15:46 ` Uriel
2008-06-11 17:53 ` Enrico Weigelt
2008-06-11 18:23 ` Russ Cox
2008-06-11 20:42 ` Roman Shaposhnik
2008-06-11 20:48 ` Enrico Weigelt
2008-06-11 20:57 ` William Josephson
2008-06-11 21:30 ` Russ Cox
2008-06-12 14:09 ` Enrico Weigelt
2008-06-11 19:28 ` Iruata Souza
2008-06-11 17:33 ` tlaronde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080611153020.GE402@nibiru.local \
--to=weigelt@metux.de \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).