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

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

[Anselm R. Garbe]

Hi there,

I created a standalone port[1] of rc found in p9p from Russ, based on
the mk-with-libs.tgz "sample". It consists of a lib9 port (including
fmt and utf like in p9p) and the rc source from src/cmd/rc. It is
currently only a proof-of-concept and I plan to clean things up
somewhat more, especially the Makefiles - and I plan to include the
manual page.

It doesn't depends on mk, because in my eyes the mk-based build chain
in p9p is rather complex.

Based on the impressions while porting it I got from p9p, I'll make
several proposals how and why one could/should modularize the whole
p9ports to reduce the monolithic character somewhat and to make it
easier to just use some libs for future development in *NIX world...

[1] http://wmi.modprobe.de/rc-with-lib9.tgz

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

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

[Federico Benavento]

> It doesn't depends on mk, because in my eyes the mk-based build chain
> in p9p is rather complex.

do you really think that?

-- 
Federico G. Benavento

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

[Anselm R. Garbe]

On 8/9/05, Federico Benavento <benavento@gmail.com> wrote:
> > It doesn't depends on mk, because in my eyes the mk-based build chain
> > in p9p is rather complex.
> 
> do you really think that?

If you only want to port 1 single tool like rc then simply yes. For
the whole p9ports the system seems adequate mostly.

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

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

[Skip Tavakkolian]

> It doesn't depends on mk, because in my eyes the mk-based build chain
> in p9p is rather complex.

see an optometrist ☺

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

[Anselm R. Garbe]

On 8/10/05, Skip Tavakkolian <9nut@9netics.com> wrote:
> > It doesn't depends on mk, because in my eyes the mk-based build chain
> > in p9p is rather complex.
> 
> see an optometrist ☺

I don't need to, nothing wrong with my eyes. Just have a look into
bin/9* and I ask why this extra-abstraction is needed... Then see
src/mk* - pretty much stuff, isn't one general inclusion sufficient?
Why are shell scripts (like INSTALL), make and mk needed? Isn't make
for bootstrapping enough and afterwards only mk?

I didn't said that the system is bad, but it can be done simplier. For
the monolithic character, the main reason to me is, that all headers
reside in $PLAN9/include, which could be done in two places, that it
is easier to just have a bunch of independent libs with their headers
and a central place (poorly there is no union mount in *NIX) where all
headers get together... Currently it is very much effort to determine
which headers are needed/provided by which lib in src/lib*...

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

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

[Gabriel Diaz]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

Hello,
 Afaik plan9ports main target is make a plan9-like environment on unix 
clones to develop in the same way plan9. And to make a program work in plan9 
and unix without modifications.
 I think that is the reason of that extra-abstraction you mention.
 may be i'm wrong, so wait for Russ comment :)
 gabi

 2005/8/10, Anselm R. Garbe <garbeam@gmail.com>: 
> 
> On 8/10/05, Skip Tavakkolian <9nut@9netics.com> wrote:
> > > It doesn't depends on mk, because in my eyes the mk-based build chain
> > > in p9p is rather complex.
> >
> > see an optometrist ☺
> 
> I don't need to, nothing wrong with my eyes. Just have a look into
> bin/9* and I ask why this extra-abstraction is needed... Then see
> src/mk* - pretty much stuff, isn't one general inclusion sufficient?
> Why are shell scripts (like INSTALL), make and mk needed? Isn't make
> for bootstrapping enough and afterwards only mk?
> 
> I didn't said that the system is bad, but it can be done simplier. For
> the monolithic character, the main reason to me is, that all headers
> reside in $PLAN9/include, which could be done in two places, that it
> is easier to just have a bunch of independent libs with their headers
> and a central place (poorly there is no union mount in *NIX) where all
> headers get together... Currently it is very much effort to determine
> which headers are needed/provided by which lib in src/lib*...
> 
> Regards,
> --
> Anselm R. Garbe ><>< www.ebrag.de <http://www.ebrag.de> ><>< GPG key: 
> 0D73F361
>

[-- Attachment #2: Type: text/html, Size: 2019 bytes --]

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

[Anselm R. Garbe]

On 8/10/05, Gabriel Diaz <gabidiaz@gmail.com> wrote:
> Afaik plan9ports main target is make a plan9-like environment on unix clones
> to develop in the same way plan9. And to make a program work in plan9 and
> unix without modifications. 
>   
> I think that is the reason of that extra-abstraction you mention. 

That makes sense, but with some modularization in mind, this could be
separated into some dev-wrapper package/directory. The main idea I got
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.

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

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

[Gabriel Diaz]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

Hi
 Well, isn't programs compiled with p9p statically linked? if so, ask 
someone to put a binaries repository, or do it yourself ?
Just one binary should work for each platform, isn't it?
 ask Russ for that posibility, i'm sure they have binaries for all the 
platform p9p supports.
 gabi

 2005/8/10, Anselm R. Garbe <garbeam@gmail.com>: 
> 
> On 8/10/05, Gabriel Diaz <gabidiaz@gmail.com> wrote:
> > Afaik plan9ports main target is make a plan9-like environment on unix 
> clones
> > to develop in the same way plan9. And to make a program work in plan9 
> and
> > unix without modifications.
> >
> > I think that is the reason of that extra-abstraction you mention.
> 
> That makes sense, but with some modularization in mind, this could be
> separated into some dev-wrapper package/directory. The main idea I got
> 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.
> 
> Regards,
> --
> Anselm R. Garbe ><>< www.ebrag.de <http://www.ebrag.de> ><>< GPG key: 
> 0D73F361
>

[-- Attachment #2: Type: text/html, Size: 1608 bytes --]

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

[Anselm R. Garbe]

Hi,

On 8/10/05, Gabriel Diaz <gabidiaz@gmail.com> wrote:
> Well, isn't programs compiled with p9p statically linked?

No, they are dynamically linked by default.

> to put a binaries repository, or do it yourself ? 

I do. But I'm referring more to developers which want link against
lib9* to depend on saner libs, than GNU libs.
Thus binary-only stuff is only one goal.

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

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

[Russ Cox]

"Porting" rc is not the most representative test case for
porting things from p9p, because rc, more than anything
else in the suite, is already a Unix program.  Secstore
would be a better test case.  It's still a simple program,
but it uses a lot more of the infrastructure.

> Just have a look into bin/9* and I ask why this
> extra-abstraction is needed... 

There are a lot of files matching 9* in bin.
	9  9a  9ar  9c	9fs  9install  9l  9p  9pserve	9.rc  9term
I assume you mean 9a, 9ar, 9c, 9l.

First and foremost, these scripts provide a standard
interface for the mkfiles to use.  9c(1) defines most
of what they guarantee to provide.  If you want to run
on a system with its own set of odd conventions, you
can accomodate them here and not change the rest of the
system.  This does happen.  (SunOS and OS X come to mind.)
If the underlying system tools need extra options (they
always do) or disagree on exactly what the flags are,
that is all hidden in these scripts instead of exposed
to every mkfile in the system.  9c invokes gcc or cc
or whatever the right compiler is -- gcc isn't the only
compiler in the world.  9a invokes the correct assembler.
9ar invokes ar, following it with ranlib if needed (some
OS X versions).  9l links the files, automatically linking
the necessary libraries.  9l alone removes a huge burden
from the mkfile writers.

Aesthetically, the scripts also help to hide the fact that
Unix has grown ridiculously long-winded in its old age.
To begin with, when I type "mk", it's a lot nicer to see

	x40=; mk
	9c  acme.c
	9c  addr.c
	9c  buff.c
	9c  cols.c
	9c  disk.c
	...

than

	x40=; mk 
	gcc -DPLAN9PORT -I/usr/local/plan9/include -O2 -c -Wall
-Wno-parentheses -Wno-missing-braces -Wno-switch -Wno-comment
-Wno-sign-compare -Wno-unknown-pragmas -fno-omit-frame-pointer -ggdb
-D__Linux26__  addr.c
	gcc -DPLAN9PORT -I/usr/local/plan9/include -O2 -c -Wall
-Wno-parentheses -Wno-missing-braces -Wno-switch -Wno-comment
-Wno-sign-compare -Wno-unknown-pragmas -fno-omit-frame-pointer -ggdb
-D__Linux26__  buff.c
	gcc -DPLAN9PORT -I/usr/local/plan9/include -O2 -c -Wall
-Wno-parentheses -Wno-missing-braces -Wno-switch -Wno-comment
-Wno-sign-compare -Wno-unknown-pragmas -fno-omit-frame-pointer -ggdb
-D__Linux26__  cols.c
	gcc -DPLAN9PORT -I/usr/local/plan9/include -O2 -c -Wall
-Wno-parentheses -Wno-missing-braces -Wno-switch -Wno-comment
-Wno-sign-compare -Wno-unknown-pragmas -fno-omit-frame-pointer -ggdb
-D__Linux26__  disk.c

because then you might actually have a chance of
noticing when the compiler prints a warning or error.
9c also reformats the output of the compiler, to put
line references in the standard line:number form on Suns,
or to increase the signal to noise ratio of the gcc errors:

	x40=; cat x.c
	int f(void) { return g; }
	x40=; 9c x.c
	x.c:1: error: `g' undeclared
	x40=; gcc -Wall x.c
	x.c: In function `f':
	x.c:1: error: `g' undeclared (first use in this function)
	x.c:1: error: (Each undeclared identifier is reported only once
	x.c:1: error: for each function it appears in.)
	x40=; 

After the first 1000 times you've seen those parenthetical
remarks by gcc, you don't need to be told again.

> src/mk* - pretty much stuff, isn't one general inclusion
> sufficient?

Mkone and mkmany might be combined (with the loss of the
default target for mkone), and mklib and mksyslib might
be combined (at the cost of every system library mkfile
knowing where the lib directory is), but all four serve
different purposes and the common bits *are* factored out
into mkcommon.  I think the situation would be worse with
just one.

See http://plan9.bell-labs.com/sys/doc/mkfiles.pdf for more
on why things are the way they are. 

> 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 with your original comment that if all you want
is rc, then working hard to build mk might be overkill.
But since my goal was to build everything anyway, making
mk as the first step isn't such a big deal.

> I didn't said that the system is bad, but it can be done
> simplier. For the monolithic character, the main reason to
> me is, that all headers reside in $PLAN9/include, which
> could be done in two places, that it is easier to just
> have a bunch of independent libs with their headers and
> a central place (poorly there is no union mount in *NIX)
> where all headers get together... Currently it is very much
> effort to determine which headers are needed/provided by
> which lib in src/lib*...

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.

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
have all the software I missed from Plan 9 building on
the many Unix systems that I am now forced to use, and to
create an environment where bringing new software over is
easy to trivial.  On this count, I think I've succeeded.
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.

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

> 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 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)
rather than change the main tree.  Lib9 in particular
is the main sticking point, since libc.h #defines a lot
of standard Unix symbols (like open and dup and pipe),
making it not suitable for use as a regular Unix library.

> > Well, isn't programs compiled with p9p statically linked?
> 
> No, they are dynamically linked by default.

You're both right.  The Plan 9 libraries are static
libraries but the system libraries underneath (-lc -lm
-lpthread) are linked the default way, which usually
dynamically.

Russ

	9pclient.h       lib9pclient
	9p.h             lib9p
	ar.h             anyone who cares (mk, libmach)
	auth.h           libauth
	authsrv.h        libauthsrv
	bin.h            libbin
	bio.h            libbio
	complete.h       libcomplete
	cursor.h         libdraw
	diskfs.h         libdiskfs
	disk.h           libdisk
	draw.h           libdraw
	event.h          libevent
	fcall.h          lib9
	flate.h          libflate
	fmt.h            libfmt (source in lib9/fmt)
	frame.h          libframe
	geometry.h       libgeometry
	html.h           libhtml
	httpd.h          libhttpd
	ip.h             libip
	keyboard.h       libdraw
	lib9.h           lib9
	libc.h           lib9 (sic)
	libsec.h         libsec
	libString.h      libString
	mach.h           libmach
	memdraw.h        libmemdraw
	memlayer.h       libmemlayer
	mouse.h          libdraw
	mp.h             libmp
	mux.h            libmux
	ndb.h            libndb
	nfs3.h           libsunrpc
	plumb.h          libplumb
	regexp9.h        libregexp
	regexp.h         libregexp
	sunrpc.h         libsunrpc
	thread.h         libthread
	u.h              (no library, system setup)
	utf.h            libutf (source in lib9/utf)
	venti.h          libventi

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

[Anselm R. Garbe]

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

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

[Ronald G Minnich]

Anselm R. Garbe wrote:

> No, they are dynamically linked by default.

um, statically linked to p9 libs and dynamically linked to linux libs, 
at least on my box:

ldd /usr/local/plan9/bin/acme
                 libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4001a000)
         libm.so.6 => /lib/i686/libm.so.6 (0x40130000)
         libutil.so.1 => /lib/libutil.so.1 (0x40153000)
         libc.so.6 => /lib/i686/libc.so.6 (0x40157000)
         libdl.so.2 => /lib/libdl.so.2 (0x4028a000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

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

[Ronald G Minnich]

I wonder if the objections to how p9p builds is the now-common syndrome 
of viewing the world through Linux and/or GNU eyes only. I see this 
frequently -- packages modified to be better on linux, or under some 
wacky GNU build environment, which then break on other OSes.

gint anyone?

It's the new definition of portable -- "It builds fine on all versions 
of gentoo I've tried, but only with kernel 2.6.9".

p9p is remarkable to me in that it builds on anything, without automake, 
configure, autoconfig, dev-wrappers, and that other horrible stuff. You 
just type make. What a concept!

GNU has somehow managed to create a "portability environment" which is 
far less portable and and far less convenient than p9p, but also about 
100 times harder to deal with. NOT progress. There's a lesson in p9p 
that I wish the GNU world would heed.

Plus, if you only want one piece, build it all anyway -- it's fast!

I don't see the problem.

ron

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

[Russ Cox]

> p9p is remarkable to me in that it builds on anything, without automake,
> configure, autoconfig, dev-wrappers, and that other horrible stuff. You
> just type make. What a concept!

Except that you spell make "./INSTALL", but yeah.

> Plus, if you only want one piece, build it all anyway -- it's fast!
> I don't see the problem.

It's not *that* fast.  Compared to a Linux kernel build, sure.
But when I'm doing regression tests to make sure that everything
still builds everywhere, I sure wish it was 10x faster.

Building everything isn't entirely realistic for some people.  If I want to
write some big program that uses libfmt for a small part, it's nice
that I can just ship the standalone libfmt instead of requiring
people to build the entire thing.  Building just libfmt is even faster.
And arguably there are a few more pieces that could stand 
on their own, though once you start dealing with 9P I think you
should just take the whole thing.

Russ

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

[Russ Cox]

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

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

[Artem Letko]

p9p doesn't build on everything - try Windows SFU 3.5 (Services for
UNIX, supposed to be POSIX something or other) for example. it still
needs "porting" to the sufficiently different but arguably UNIX-like
environment. but i agree on everything else ron said.

-art

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

[Anselm R. Garbe]

On 8/10/05, Ronald G Minnich <rminnich@lanl.gov> wrote:
> I wonder if the objections to how p9p builds is the now-common syndrome
> of viewing the world through Linux and/or GNU eyes only. I see this
> frequently -- packages modified to be better on linux, or under some
> wacky GNU build environment, which then break on other OSes.

Nah, that was not my point, then we misunderstood each other. I don't
like the GNU way as well. My impression can be summed up to "why using
shell scripts, make and mk - instead of make and mk" - which means
getting rid of shell scripts at first glance seemed me to make it
simplier. But as mentioned I understand the sense of 9* shell scripts.

> It's the new definition of portable -- "It builds fine on all versions
> of gentoo I've tried, but only with kernel 2.6.9".
> 
> p9p is remarkable to me in that it builds on anything, without automake,
> configure, autoconfig, dev-wrappers, and that other horrible stuff. You
> just type make. What a concept!
> 
> GNU has somehow managed to create a "portability environment" which is
> far less portable and and far less convenient than p9p, but also about
> 100 times harder to deal with. NOT progress. There's a lesson in p9p
> that I wish the GNU world would heed.

Tell that the GNU morons, I'm hopefully far away from them... I prefer
one system, wether make or mk doesn't matters and try to reduce all
additional dependencies when possible. Maybe the GNU world prefers
shell scripts+m4+autoconf+automake+Make+ant+wtf to build their
software, because they want to notice the build process at a speed
level with todays computers they can follow (./configure == for each
line; perform line; sleep 2s; continue;)...

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

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

[Ronald G Minnich]

Artem Letko wrote:
> p9p doesn't build on everything - try Windows SFU 3.5 


actually, the name started out was windows for unix, i.e. W FU (or maybe 
Windows! -- FU), but I think it had to change for some reason.

ron
p.s. I think I'm joking, but how could one tell?

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

[Anselm R. Garbe]

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

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

[Andy Newman]

Ronald G Minnich wrote:
> actually, the name started out was windows for unix, i.e. W FU (or maybe 
> Windows! -- FU), but I think it had to change for some reason.
> 
> ron
> p.s. I think I'm joking, but how could one tell?

Truth is stranger than fiction... They (MS) had to rename
their Critical Update Notification Tool when someone figured
it out.  References to it have been "disappeared" but Google
and friends had copies at one time.