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

I know that fact, but we argue from different intentions. Imagine p9p
from my point of view, which could look like a pool of independent
lib- and userland tarballs/directories you can choose from like they
are needed. Ie. if you're going to use the development tools you just
extract the contents of the comp.tgz tarball or whatever one might
call it, which contains the 9* shell scripts beside mk and maybe some
other things. This would also be needed if you're going to build p9p.
But imagined that you normally use Makefiles in your projects you
might not need to extract the comp.tgz, maybe only some libs you want
to depend on or even only a tool like rc. I see much potential
especially in the library usage of p9p in a classical unix
environment. Look at all those bloated GNU libs and you feel well once
looking into plan9 libs. That's the point why I'm arguing here. There
might be a broad audience of developers out there interested in
adapting original plan9 stuff in classical unix projects, without
depending on the p9ports as a whole.
If there might be a way to achieve both intentions, your and mine,
with a single (semi?-)modularized p9p tree, one could profit from each
other. Especially I see p9ports as one of the most important projects
for people getting in contact with plan9 world/ideas... Thus I
consider those thoughts as important, because p9p might provide the
chance to strengthen the efforts of an active p9 development again in
gaining new developers through p9p - maybe it's a dream, but we'll
see.

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

Sure, agreed.

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

That must be an emberrassement.

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

You can, and I doesn't care much :)

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