[9fans] build system: [was: (no subject)]


Of course, one would then be tempted (as I have been) to look more
seriously at porting the NetBSD package system to Plan 9. That's not
out of the question, in fact it's probably not too difficult, but the
residual pain of autoconf for each individual package has already
frightened people with a stronger stomach than mine away. That is why
I cannot suggest we catch up, but it may be nice to be ready when
eventually the autoconf edifice falls down and something mildly
intelligent takes its place!

Ironically, Plan 9 may be the platform on which a replacement for
autoconf could be designed and implemented. But that's too close to a
pipedream to be given serious consideration.

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'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.

EBo --

.

Relevant Pages

  • Re: [9fans] (no subject)
    ... It's autoconf that needs careful ... revision control even when backed by venti, it is unmatched for Plan 9 ... But that leaves one still at the mercy of autoconf and it ... seems to me that the trigger for change ought to come from Plan 9. ...
    (comp.os.plan9)
  • Re: [9fans] (no subject)
    ... I'd use the NetBSD packages DESCR files in ... seriously at porting the NetBSD package system to Plan 9. ... residual pain of autoconf for each individual package has already ...
    (comp.os.plan9)
  • Re: Comments on pmake diffs for building on Linux
    ... and I don't plan to commit them ... (a portable NetBSD make) ... I dare say you could just grab the autoconf ...
    (freebsd-hackers)