From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190610201639w3b5fee28tb05ab2c8d158f984@mail.gmail.com>
Date: Sat, 21 Oct 2006 09:39:44 +1000
From: "Bruce Ellis" <bruce.ellis@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Include guards and multiple includes
In-Reply-To: <52af7b0e92c11760a5b9d627fd71aa09@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <219D85AA-959D-464C-90C2-0F132809F0B9@telus.net>
	<52af7b0e92c11760a5b9d627fd71aa09@plan9.bell-labs.com>
Topicbox-Message-UUID: cf98ebc2-ead1-11e9-9d60-3106f5b1d025

an appropriate answer is unfortunately "it doesn't matter,
it'll probably change next week anyway".  the linux kernel
is more fascinating.  ask "is this bit of code ever executed"
or "where is this function called/defined".

brucee

On 10/21/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> I think that one of the best arguments for organising header files as
> Plan 9 does is the mess that /usr/include has become on (l)unix.  It's
> almost 20MB on Suse 9.1.
>
> Here's an interesting exercise for people who don't see a problem with
> how (l)unix organises /usr/include:
>
> Ask someone (ideally a manager, the higher the rank, the better) to
> find out where under /usr/include on Linux the type time_t is defined
> and the signal SIGINT is declared without using grep or any
> equivalent; they should trace through the include files visually.  If
> they return with the correct answers and aren't disgusted with the
> mess under /usr/include, slap some pointy hair on them.
>
>