9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Uriel <uriel99@gmail.com>
To: weigelt@metux.de,
	"Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] Modularizing plan9port
Date: Wed, 11 Jun 2008 17:46:28 +0200	[thread overview]
Message-ID: <5d375e920806110846k6cfcfa68kd7ce14cfd3858e90@mail.gmail.com> (raw)
In-Reply-To: <5d375e920806110843w3267df9anebe733e4231b6893@mail.gmail.com>

By the way, silly question, but what would it take to have the kencc
port accepted as part of p9p?

And a port of of plan9's awk (trivial to do)? It would be nice to be
able to rely on a decent utf-8 enabled awk when writing scripts for
p9p without worrying about what broken awk does this or that *nix have
installed.

uriel

On Wed, Jun 11, 2008 at 5:43 PM, Uriel <uriel99@gmail.com> wrote:
> If you want to cross-compile why don't you use Plan 9? or at least the
> port of the plan9 compilers to lunix[1], where cross compiling is the
> only way to compile.
>
> Cross-compiling in Gnu/land is a nightmare not worth going into.
>
> uriel
>
> [1] http://gsoc.cat-v.org/projects/kencc/
>
> On Wed, Jun 11, 2008 at 5:30 PM, Enrico Weigelt <weigelt@metux.de> wrote:
>> * 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
>> ----------------------------------------------------------------------
>>
>>
>



  reply	other threads:[~2008-06-11 15:46 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
2008-06-11 15:43     ` Uriel
2008-06-11 15:46       ` Uriel [this message]
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=5d375e920806110846k6cfcfa68kd7ce14cfd3858e90@mail.gmail.com \
    --to=uriel99@gmail.com \
    --cc=9fans@9fans.net \
    --cc=weigelt@metux.de \
    /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).