Re: [9fans] (no subject)

I only strongly suggest that you put the contrib gui at the heart of
what the user sees.

Agreed wholeheartedly. Thing is, It's autoconf that needs careful
redesign: even though contrib/replica is not as comprehensive as a
revision control even when backed by venti, it is unmatched for Plan 9
purposes. 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.
And in case I haven't yet made it clear, I don't have a good enough
picture in my head to suggest a replacement.

In fact, Steve Simon and fgb both have done great work to help there,
but I feel the real answer is still at large.

And if anyone should find this bait irresistible, keep in mind that
the final product needs to be portable across at least a few OS
platforms as well as hardware architectures and that it should
probably be targetting the Plan 9 toolchain rather than GCC (G++ is a
problem, of course, but Go may help there as at least with the NetBSD
packages, the number of C++ offerings is limited.).

++L


.

Relevant Pages

  • [9fans] build system: [was: (no subject)]
    ... seriously at porting the NetBSD package system to Plan 9. ... residual pain of autoconf for each individual package has already ... Take a look at Boost's port of Perforce Software's build tool Jam ...
    (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)