Re: [9fans] Standalone unix port of the original rc shell

["Anselm R. Garbe" <garbeam@gmail.com>]

On 8/10/05, Russ Cox <russcox@gmail.com> wrote:
> > Why are shell scripts (like INSTALL), make and mk
> > needed? Isn't make for bootstrapping enough and afterwards
> > only mk?
> 
> Isn't this how it works now?  I admit that I could remove
> the reliance on make pretty easily, but everyone has make.
> Once the system is installed, only mk is used.  INSTALL is
> just a convenience to get you started.

I agree on your points and they make sense with your intention of
plan9ports. Thus if you got wrappers for 9a, 9ar, 9c and 9l which are
shell scripts one can live with INSTALL, although in Unix world at
least the more common way for toolchains would be make world or make
install. But well, a detail with minor priority.
Personally I hide that verbose gcc output using:

<target>:
\t@echo CC $*.c
\t@CC ...

This works on all make versions. But from plan9 from user space view
the 9* wrappers seem straight forward, especially if typical p9
mkfile's use those commands one has minimal effort to port them.

> Grep for AUTOLIB in the headers and you'll find out which
> libraries they need to be linked with.  In fact, 9l will
> do the linking for you.  As for which headers are provided
> by which library, the usual rule is that foo.h or libfoo.h
> goes with $PLAN9/src/libfoo.  There are a few exceptions
> but that is by far the norm.  An annotated list of the
> header files is below.  In any event, the header situation
> is far simpler than it is in Unix.

Thx for the hint, also for the annotated list which is very helpful.

> I think the main tension here is that you're trying
> to view Plan 9 from User Space as a new piece of Unix
> software, and you're expecting it to conform to the
> Unix conventions.  This isn't always a bad thing to do,
> but it isn't my first priority.  My first priority is to

Yea, I understand that.

> In fact, a week or two ago, instead of trying to set up
> an lpr or cups server on my Debian system, I ported Plan
> 9's lp, which took under an hour.

Hehe...

> > That makes sense, but with some modularization in
> > mind, this could be separated into some dev-wrapper
> > package/directory.
> 
> I don't know what a dev-wrapper package/directory is,
> but it sounds scary.

It's just a separation of 9a, 9ar, 9l, 9c and the INSTALL/make stuff
to some toolchain/ directory - somewhat more strict than the current
way.

> > The main idea is to modularize the whole p9p into
> > sub-pieces, that one don't needs to install all 420kSLOC
> > if one wants only depend on some p9 libs or on some bits
> > of the whole thing, ie acme only.
> 
> Yes, please, try it.  I'm be interested to see what you
> come up with.

I'm going to try it for the stuff I'm interested in/liking to depend on.

> I would like to see more libraries separated out so
> that other projects can use them without the whole tree.
> I think (but am not sure) that the best way to do this
> is to separate them explicitly (look in $PLAN9/unix for
> the scripts that pull out utf, fmt, bio, regexp, and mk)

Yea, that would not change your concept and is a nice separate place
to start with.

Regards,
-- 
  Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361