Re: configuration problems

From: williamkempf_at_[hidden]
Date: 2001-03-15 13:39:05

--- In boost_at_y..., kevin_vanhorn_at_n... wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> >> 2. Why not use a configure script to figure out what C++ features
> >> the compiler/standard library support and so generate
> >> <boost/config.hpp>?
> > 
> > Several people have mentioned this approach in the past.  Could 
you
> > explain how that would work in a platform and toolset independent
> > way?
> 
> Truth to tell, I'm still learning the details of this stuff myself. 
> Here's what I know.  To allow portability between the wide variety 
of
> Unix and Unix-like systems out there, a lot of free software used in
> the Unix world comes with a configure shell script that you run 
first
> before building the software.  The configure script runs tests to
> check for the existence of various utilities, header files, 
functions,
> libraries, etc, and produces an appropriate Makefile from a template
> as well as (sometimes) creating a config.h header file.  I believe
> that it does some of these tests by trying to compile various code
> snippets and seeing if the compilation succeeds and (in some cases)
> checking that the compiled code behaves as expected.

The problem is, this is limited to "Unix and Unix-like systems".

> There is a free tool called autoconf to assist one in the creation 
of
> such scripts.  This stuff can run on Windows as well, if you have 
the
> Cygwin tools installed.

The Cygwin tools are not an option for Boost.  We can't require Win32 
users to d/l this toolset just to use Boost.  This is what Beman 
meant when he asked if you knew of a "portable" way.

BTW, even if we allowed this and required Win32 uers to grab the 
Cygwin tools, you'd still be leaving Mac users, BeOS users, Amiga 
users, etc. out.  A solution here must truly be portable and require 
no tools or libraries that are either not supplied by the OS "out of 
the box" or that are not included in Boost itself.  I know that this 
frustrates Unix users who are used to using certain tools 
for "portability", but for those of us not on Unix this is a very 
good thing.

Bill Kempf