9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: lucio@proxima.alt.za
To: ebo@sandien.com, 9fans@9fans.net
Subject: Re: [9fans] build system:  [was: (no subject)]
Date: Sun,  7 Mar 2010 19:22:58 +0200	[thread overview]
Message-ID: <d50751934726ff8f2991691b5c475494@proxima.alt.za> (raw)
In-Reply-To: <twig.1267969093.35494@swcp.com>

> Take a look at Boost's port of Perforce Software's build tool Jam
> <http://www.boost.org/doc/tools/jam/index.html>.  What little I have used it
> in the past it came across as a much more elegant tool-chain.  Now what I
> would LOVE to see is a port of Joel de Gusman's Spirit++.  Well I can dream
> cannt I ;-)
>
I do believe there are valiant efforts out there, problem is that they
are solutions outside the problem space.  Or, in other words, there
aren't valiant users for them, at least not in significant numbers.

> I've also started on updating an old per-application portage ebuild based on
> Anant's work back in 2007.  If that is of any interest maybe I could get you
> to either collaborate or just do a little testing.

All options are good, if you think I can help in any way, feel free to
mail me off list.

What I guess is the best we can ask for right now is that various
developers keep the finger on the pulse of Open Source fashion and be
ready when the fashion swings willy-nilly to a more practical
portability enhancement toolset than autoconf.  My own bet and
investment is in Go, more with the Plan 9 toolchain port to Unix in
mind than with the language itself, at least until the language
establishes itself.  And before anyone is miffed, I do like the
lanquage, but the port to Plan 9 is proceeding too slowly for my
liking, specially my own efforts.

We know that Plan 9 provides a more stable foundation for portability
across architectures and much of that strength lies in the toolchain,
so I'm putting my money there, even though I think I note a weakness I
can't quite figure out how best to address regarding portability
across OS platforms.

Others will almost certainly pip me to the post regarding
configuration flexibility as presently faked by autoconf.  I'm not
going to go there any time soon, although I am aware of the need: my
plate is full as it is.

++L




      parent reply	other threads:[~2010-03-07 17:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-07 13:38 EBo
2010-03-07 16:31 ` erik quanstrom
2010-03-11 17:14   ` EBo
2010-03-11 17:47     ` David Leimbach
2010-03-07 17:22 ` lucio [this message]

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=d50751934726ff8f2991691b5c475494@proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@9fans.net \
    --cc=ebo@sandien.com \
    /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).