From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 10 Aug 2005 11:31:02 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Standalone unix port of the original rc shell In-Reply-To: <89d1e7b80508100723784161bb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <89d1e7b805080907166daf05ae@mail.gmail.com> <89d1e7b8050810030348f99ef0@mail.gmail.com> <89d1e7b80508100723784161bb@mail.gmail.com> Topicbox-Message-UUID: 75cfcac6-ead0-11e9-9d60-3106f5b1d025 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: >=20 > : > \t@echo CC $*.c > \t@CC ... > This works on all make versions.=20 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.=20 > > 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. >=20 > 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. >=20 > 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=20 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