From owner-freebsd-hackers Fri Apr 11 19:51:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA09911 for hackers-outgoing; Fri, 11 Apr 1997 19:51:00 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA09903 for ; Fri, 11 Apr 1997 19:50:52 -0700 (PDT) Message-Id: <199704120250.TAA09903@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA035053059; Sat, 12 Apr 1997 12:44:19 +1000 From: Darren Reed Subject: Re: detecting kernel version at compile time To: proff@suburbia.net Date: Sat, 12 Apr 1997 12:44:19 +1000 (EST) Cc: avalon@coombs.anu.edu.au, terry@lambert.org, hackers@freebsd.org In-Reply-To: <19970411002900.15347.qmail@suburbia.net> from "proff@suburbia.net" at Apr 11, 97 10:28:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from proff@suburbia.net, sie said: > > > You are deceiving yourselves if you think you are just making life > > easier for everyone. Any change implies more work from 3rd party > > developers to accomodate that change. > > Right but look at the alternative (attached below). You can quite > rightly say that this horror is required regardless. But the reality > is that the present does indeed become the past and in two years > time one can expect users to be running at least what we have as > -current now. That is why it is important to create an environment > that accommodates change as soon as possible, so during the course > of the next two years monstrosity below can be reduced to: > > #include [...] Here here.