* [9fans] Standalone unix port of the original rc shell @ 2005-08-09 14:16 Anselm R. Garbe 2005-08-09 15:22 ` Federico Benavento 2005-08-10 5:54 ` Skip Tavakkolian 0 siblings, 2 replies; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-09 14:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-09 14:16 [9fans] Standalone unix port of the original rc shell Anselm R. Garbe @ 2005-08-09 15:22 ` Federico Benavento 2005-08-09 15:28 ` Anselm R. Garbe 2005-08-10 5:54 ` Skip Tavakkolian 1 sibling, 1 reply; 20+ messages in thread From: Federico Benavento @ 2005-08-09 15:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-09 15:22 ` Federico Benavento @ 2005-08-09 15:28 ` Anselm R. Garbe 0 siblings, 0 replies; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-09 15:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-09 14:16 [9fans] Standalone unix port of the original rc shell Anselm R. Garbe 2005-08-09 15:22 ` Federico Benavento @ 2005-08-10 5:54 ` Skip Tavakkolian 2005-08-10 10:03 ` Anselm R. Garbe 1 sibling, 1 reply; 20+ messages in thread From: Skip Tavakkolian @ 2005-08-10 5:54 UTC (permalink / raw) To: 9fans > It doesn't depends on mk, because in my eyes the mk-based build chain > in p9p is rather complex. see an optometrist ☺ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 5:54 ` Skip Tavakkolian @ 2005-08-10 10:03 ` Anselm R. Garbe 2005-08-10 10:29 ` Gabriel Diaz 2005-08-10 13:50 ` Russ Cox 0 siblings, 2 replies; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 10:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 10:03 ` Anselm R. Garbe @ 2005-08-10 10:29 ` Gabriel Diaz 2005-08-10 12:38 ` Anselm R. Garbe 2005-08-10 13:50 ` Russ Cox 1 sibling, 1 reply; 20+ messages in thread From: Gabriel Diaz @ 2005-08-10 10:29 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 10:29 ` Gabriel Diaz @ 2005-08-10 12:38 ` Anselm R. Garbe 2005-08-10 12:43 ` Gabriel Diaz 0 siblings, 1 reply; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 12:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 12:38 ` Anselm R. Garbe @ 2005-08-10 12:43 ` Gabriel Diaz 2005-08-10 12:57 ` Anselm R. Garbe 0 siblings, 1 reply; 20+ messages in thread From: Gabriel Diaz @ 2005-08-10 12:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 12:43 ` Gabriel Diaz @ 2005-08-10 12:57 ` Anselm R. Garbe 2005-08-10 14:55 ` Ronald G Minnich 0 siblings, 1 reply; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 12:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 12:57 ` Anselm R. Garbe @ 2005-08-10 14:55 ` Ronald G Minnich 0 siblings, 0 replies; 20+ messages in thread From: Ronald G Minnich @ 2005-08-10 14:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 10:03 ` Anselm R. Garbe 2005-08-10 10:29 ` Gabriel Diaz @ 2005-08-10 13:50 ` Russ Cox 2005-08-10 14:23 ` Anselm R. Garbe 2005-08-10 15:04 ` Ronald G Minnich 1 sibling, 2 replies; 20+ messages in thread From: Russ Cox @ 2005-08-10 13:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs "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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 13:50 ` Russ Cox @ 2005-08-10 14:23 ` Anselm R. Garbe 2005-08-10 15:31 ` Russ Cox 2005-08-10 15:04 ` Ronald G Minnich 1 sibling, 1 reply; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 14:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 14:23 ` Anselm R. Garbe @ 2005-08-10 15:31 ` Russ Cox 2005-08-10 15:52 ` Anselm R. Garbe 0 siblings, 1 reply; 20+ messages in thread From: Russ Cox @ 2005-08-10 15:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:31 ` Russ Cox @ 2005-08-10 15:52 ` Anselm R. Garbe 0 siblings, 0 replies; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 15:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 13:50 ` Russ Cox 2005-08-10 14:23 ` Anselm R. Garbe @ 2005-08-10 15:04 ` Ronald G Minnich 2005-08-10 15:18 ` Russ Cox ` (2 more replies) 1 sibling, 3 replies; 20+ messages in thread From: Ronald G Minnich @ 2005-08-10 15:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:04 ` Ronald G Minnich @ 2005-08-10 15:18 ` Russ Cox 2005-08-10 15:33 ` Artem Letko 2005-08-10 15:36 ` Anselm R. Garbe 2 siblings, 0 replies; 20+ messages in thread From: Russ Cox @ 2005-08-10 15:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:04 ` Ronald G Minnich 2005-08-10 15:18 ` Russ Cox @ 2005-08-10 15:33 ` Artem Letko 2005-08-10 15:38 ` Ronald G Minnich 2005-08-10 15:36 ` Anselm R. Garbe 2 siblings, 1 reply; 20+ messages in thread From: Artem Letko @ 2005-08-10 15:33 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:33 ` Artem Letko @ 2005-08-10 15:38 ` Ronald G Minnich 2005-08-10 22:34 ` Andy Newman 0 siblings, 1 reply; 20+ messages in thread From: Ronald G Minnich @ 2005-08-10 15:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:38 ` Ronald G Minnich @ 2005-08-10 22:34 ` Andy Newman 0 siblings, 0 replies; 20+ messages in thread From: Andy Newman @ 2005-08-10 22:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [9fans] Standalone unix port of the original rc shell 2005-08-10 15:04 ` Ronald G Minnich 2005-08-10 15:18 ` Russ Cox 2005-08-10 15:33 ` Artem Letko @ 2005-08-10 15:36 ` Anselm R. Garbe 2 siblings, 0 replies; 20+ messages in thread From: Anselm R. Garbe @ 2005-08-10 15:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-08-10 22:34 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-09 14:16 [9fans] Standalone unix port of the original rc shell Anselm R. Garbe 2005-08-09 15:22 ` Federico Benavento 2005-08-09 15:28 ` Anselm R. Garbe 2005-08-10 5:54 ` Skip Tavakkolian 2005-08-10 10:03 ` Anselm R. Garbe 2005-08-10 10:29 ` Gabriel Diaz 2005-08-10 12:38 ` Anselm R. Garbe 2005-08-10 12:43 ` Gabriel Diaz 2005-08-10 12:57 ` Anselm R. Garbe 2005-08-10 14:55 ` Ronald G Minnich 2005-08-10 13:50 ` Russ Cox 2005-08-10 14:23 ` Anselm R. Garbe 2005-08-10 15:31 ` Russ Cox 2005-08-10 15:52 ` Anselm R. Garbe 2005-08-10 15:04 ` Ronald G Minnich 2005-08-10 15:18 ` Russ Cox 2005-08-10 15:33 ` Artem Letko 2005-08-10 15:38 ` Ronald G Minnich 2005-08-10 22:34 ` Andy Newman 2005-08-10 15:36 ` Anselm R. Garbe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).