httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: Apache 1.1b4... where is it?
Date Wed, 19 Jun 1996 09:37:53 GMT
Paul Richards wrote:
> 
> >>>>> "Brian" == Brian Behlendorf <brian@organic.com> writes:
> 
> Brian> On Mon, 17 Jun 1996, Tom Tromey wrote:
> >> >> 2) Autoconfiscation
> >> 
> 
> Brian> There is an interesting compromise - use autoconf-style
> Brian> #define's, and still distribute a Configuration document which
> Brian> contains #define settings for a majority of platforms, with the
> Brian> statement "if your platform is not listed here, please run the
> Brian> 'try-new-configuration' script to see if we can detect what
> Brian> settings your platform needs".  That would eliminate the need
> Brian> for most people to run the autoconf Configure program.
> 
> 
> We need to adopt a standard set of defines in any case and I see no
> reason why we couldn't use autoconf's. This does allow an interesting
> compromise in that people can run autoconf to generate a config.h that
> would actually work with Apache while those of us who don't like it much
> (personally I just get fed up of waiting for it to analyse my system and
> writing a one-off config file for an OS makes me happier) can use
> fixed config files.
> 
> ok, how about this then.
> 
> We create a config directory which contains an osname.h file which holds
> all the defines for that OS. The format of that file is such that it's
> compatible with the naming scheme that a config.h from autoconf would
> generate.
> 
> The Makefile contains a config target that does a 'uname' and copies the
> config/osname.h to ./config.h if such a file exists, otherwise it prints
> out a message saying that the OS is not pre-configured and that the user
> should try running autoconf and submitting the generated config.h to the
> Apache group for inclusion in config/ in the next release and from the
> submitted file we can create an osname.h.

Just a small point. SCO is, as usual, brain dead wrt uname, output from uname
on SCO 3:

4237$ uname
gonzo
4238$ uname -a
gonzo gonzo 3.2 2 i386

The machine's name is gonzo, BTW.

And SCO 5:

464$ uname
SCO_SV
466$ uname -a
SCO_SV scuzzy 3.2 2 i386

Nice, huh? The one that actually tells you anything useful is uname -X:

SCO3:

4239$ uname -X

System = gonzo
Node = gonzo
Release = 3.2v4.2
KernelID = 94/02/14
Machine = Pentium
BusType = ISA
Serial = XXXXXXXXX
Users = 16-user
OEM# = 0
Origin# = 1
NumCPU = 1

SCO 5:

467$ uname -X

System = SCO_SV
Node = scuzzy
Release = 3.2v5.0.0
KernelID = 95/08/08
Machine = Pentium
BusType = ISA
Serial = XXXXXXXXX
Users = 16-user
OEM# = 0
Origin# = 1
NumCPU = 1

Cheers,

Ben.

> 
> That *should* make our build system much cleaner for the supported OS's and
> still be able to live alongside the autoconf mechanism for those that
> prefer to use it. We'd just have to try it and see if it works.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message