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

[Russ Cox <russcox@gmail.com>]

It sounds like you are missing the fact that 9c, 9a, etc.
are not just scaffolding used to build the rest of the
system.  They're also user commands just like cat and ls.
I'm sure that some days I run 9c by hand 100 times or more.
It's not so easy when you have to type the equivalent
ridiculously long gcc command line instead.

> Personally I hide that verbose gcc output using:
> 
> <target>:
> \t@echo CC $*.c
> \t@CC ...
> This works on all make versions. 

If one only ever invoked the compiler via make, this might
be a reasonable approach.  (It still wouldn't be optimal, since
you'd still go nuts maintaining your CFLAGS variable.)  But
what about when you want to run it from the command line?
Make's output has the nice property that, until you start doing
tricks like that, it's executable.

I use the above make trick on a different project I'm working
on with a bunch of Unix-heads, but it has the disadvantage that
when a source file fails to compile, you can't just snarf and send
the CC line to try recompiling it. 

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

In return I expect an annotated list of all the headers on a typical
Linux system.

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

Again, those are real programs just like cat and ls.
There's no need to hide them.  I could put INSTALL 
into a makefile, but that's kind of a silly argument.
Everyone else has a top-level script called ./configure.
Why can't I have one called ./INSTALL?  I'll throw away
the toplevel makefile if it will make you happy.

Russ