[9fans] 9libs, new sam release, experimental wily release

[9fans] 9libs, new sam release, experimental wily release

[okamoto]

Are you going to make change to the other unix programs for Plan 9
emulation, such as 9term?

Kenji

[9fans] 9libs, new sam release, experimental wily release

[Mark]

okamoto@granite.cias.osakafu-u.ac.JP wrote:

> Are you going to make change to the other unix programs for Plan 9
> emulation, such as 9term?

Hopefully. Matty Farrow mentioned to me that he was thinking of doing a
new 9term release, and I'd certainly be prepared to help out with the
build system for it. The handling of pseudo terminals is probably the
worst bit.

-Mark.

[9fans] 9libs, new sam release, experimental wily release

[Tim]

In article <199906111008.GAA08404@cse.psu.edu>,  <forsyth@vitanuova.COM> wrote:
>it would be nice if someone did a general but sane configuration method for the gnu software
>to replace the existing configure crud.

Yup.  It's effective, but not pretty.  In the rc-1.6 distribution,
`configure' is the largest file by a factor of more than 2; it is over 9
times larger than any C source file except the yacc-generated parse.c.
Both Makefile.in and aclocal.m4 are also larger than any source files;
between the three of them, they make up over 25% over the distribution.
Still, they probably compress better than most of the other files :-).

I think the approach taken by some of Dan Bernstein's software is
probably along the right lines.  Here's a snippet from the Makefile of
his clockspeed package.

    hasrdtsc.h: \
    tryrdtsc.c compile load
            ( ( ./compile tryrdtsc.c && ./load tryrdtsc && ./tryrdtsc \
            ) >/dev/null 2>&1 \
            && echo \#define HASRDTSC 1 || exit 0 ) > hasrdtsc.h
            rm -f tryrdtsc.o tryrdtsc

In case it's not obvious, this attempts to compile, load, and run
the program tryrdtsc.c.  If it can be built, and runs successfully,
hasrdtsc.h will contain the single line `#define HASRDTSC 1'; otherwise
it will be empty.

The autoconf equivalent would be something along these lines.

    AC_DEFUN(TRY_RDTSC, [
        AC_CACHE_CHECK(for Pentium RTDSC instruction, try_rdtsc,
            AC_TRY_RUN([
    <text of tryrdtsc.c goes here>
             ], try_rdtsc=yes, try_rdtsc=no, try_rdtsc=yes))
             case "$try_rdtsc" in
             yes) AC_DEFINE(HASRDTSC) ;;
             esac
     ])

It's obvious how to make the trivial changes to Bernstein's Makefile
to produce the equivalent of autoconf's AC_TRY_LINK or AC_TRY_COMPILE.
With AC_TRY_RUN, the three macros form the basis of almost all sensible
autoconf checks.

How do the two systems compare?

The autoconf version is longer, even in the configure.in version.  It
expands to about 40 lines of even more impenetrable shell script after
processing.

For all that extra code, the only extra features I can see in the
autoconf version are: i) it tells the user what it is doing, and
ii) there is "support" for cross-compiling.  Well, most users don't
have a clue what the Pentium RDTSC instruction is anyway; a comment
in tryrtdsc.c would be as helpful to those that do care.  As for
cross-compilation: autoconf knows when you're cross-compiling, and
substitutes a default value.  If there is a useful default value, why
would we bother with autoconf in the first place?  Bernstein's system
encourages the savvy installer to run the test program on the target
machine, and create the *correct* hasrdtsc.h.

Both systems feature caching.  The configure script builds a
config.cache; Bernstein simply uses make's dependency rules.  When
you are developing feature tests, config.cache is at completely the
wrong granularity.  With autoconf, I'd have to fire up an editor on
config.cache, find the line that mentions try_rdtsc, remove it, then
rerun the *entire* configure script.  With Bernstein, it's just `rm
hasrdtsc.h; make'.

Speaking of granularity, autoconf dumps all its discoveries about
the system into a single config.h.  Any C source file that needs a
feature test depends on config.h; changing the result of one test means
recompiling all of them.  (In rc's case, this turns out to be *every*
C file; I'm afraid I was a bit lazy here.)  This, of course, is why
autoconf must go through hoops to avoid replacing config.h with a newly
generated, but identical, one.

I'm seriously considering dumping autoconf / automake as the build
engine for rc(the next generation), and using something more like
Bernstein's system.  (Unfortunately, I don't think he's made the
framework generally available; I gather that his Makefiles are
automatically generated.  Still, I could probably reimplement the whole
lot in about the time it takes to get the quoting right on one autoconf
macro.)

Apologies for the length...

Tim.

[9fans] 9libs, new sam release, experimental wily release

[forsyth]

>>system which uses a GNU-style configure script and which will build
>>shared libraries using GNU libtool. The intention is to make it easier

it would be nice if someone did a general but sane configuration method for the gnu software
to replace the existing configure crud.

[9fans] 9libs, new sam release, experimental wily release

[Mark]

We would like to announce the release of the following bundles of code:

 * 9libs-1.0, a collection of libraries which emulate some parts of the
   Plan 9 programming environment under Unix and the X Window System.
 * sam-9libs, a new release of Rob Pike's editor, sam, which uses 9libs-1.0.
 * wily-9libs, an experimental release of Gary Capell's editor, wily, which
   emulates the functionality of Rob's editor "acme" from Plan 9. Again,
   wily-9libs uses 9libs.

9libs-1.0 is a repackaging of libXg, libframe and libregexp from the last
release of sam. It replaces the collection of Makefiles with a build
system which uses a GNU-style configure script and which will build
shared libraries using GNU libtool. The intention is to make it easier
to compile and install the libraries (and applications which use them)
on modern Unix systems. It also adds some new implementations of Plan 9
functions (notably the print() functions) which have been grouped with
libregexp into a new library called libplan9c.

sam-9libs is a new release of sam which links against the libraries
from 9libs-1.0. Other than changes in the build system there is only
one new feature: sam uses the value of the environment variable TABSTOP
to set the size of its tabstop. It is intended that this release of sam
become the "official" release: the version of samterm which Bell Labs
run on brazil uses a newer graphics model than that provided by libg
(and libXg). As such it is growing increasingly difficult for them to
support this older version.

wily-9libs is an experimental (as in "not official") release of
wily-0.13.43 which has been modified to build against 9libs. It also
adds an implementation of the Font builtin which more closely emulates
the same builtin in acme.

You can get the code from the following locations:

	ftp://netlib.bell-labs.com/netlib/research/9libs
	ftp://ftp.demon.co.uk/pub/unix/plan9

Why would you want to use this? Basically, it makes your life easier.
You can compile and install 9libs, sam and wily separately if you want.
You can also build the whole lot together: it's as simple as this:

	; gunzip -c 9libs-1.0.tar.gz | tar xf -
	; cd 9libs-1.0
	; gunzip -c ../sam-9libs.tar.gz | tar xf -
	; gunzip -c ../wily-9libs.tar.gz | tar xf -
	; ./configure
	; make

The build system also supports building for multiple architectures from
one directory tree.

Enjoy!

Mark Wilkinson <mhw@kremvax.demon.co.uk>
Bengt Kleberg <bengt@softwell.se>