Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-23 19:41:39


At 06:40 PM 2/23/00 -0500, Braden N. McDaniel wrote:

>On Wed, 23 Feb 2000, Jens Maurer wrote:
>
>>
>> "Braden N. McDaniel" wrote:
>> > GNU autoconf/automake/libtool cover a pretty broad range of
platforms. Not
>> > Mac (though I think there's a good deal of hope for OS X support
in the
>> > future), and Windows support is limited to Cygwin.
>>
>> For Unix, we should definitely go "autoconf".
>> With <boost/config.hpp>, we've got a "tell me the name of your
compiler,
>> I tell you what features it has" approach. "autoconf" has the
>> philosophy of "whatever is there, let's try out what it supports".
>> That means, "autoconf" has the (slight) chance to support more
>> platforms than those that were known to exist at
<boost/config.hpp>
>> production time. Besides, the autoconf approach scales linearily
with
>> the number of (mis-)features, while the (current)
<boost/config.hpp> scales
>> with (number of (mis-)features) times (number of
compilers/environments).
>
>This is all true, but the current scheme of using "config.hpp" does
have
>the benefit of being cross-platform (more or less). If boost were to
use
>an autoconf-generated config header, things would be a bit tidier
for
>platforms with autoconf, yet it seems like we'd end up with
>platform-specific config files for the other platforms.
>
>Note to those unfamiliar with autoconf: This is not an issue that
would
>likely determine *whether* boost could use autoconf, just exactly
how we
>would employ it.

Isn't the issue of how to configure for a given platform separable
from how to build the binary library for the platform? Of course, if
any configuration has to be done, it must be done first.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk