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
>> 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
>> production time. Besides, the autoconf approach scales linearily
>> the number of (mis-)features, while the (current)
<boost/config.hpp> scales
>> with (number of (mis-)features) times (number of
>This is all true, but the current scheme of using "config.hpp" does
>the benefit of being cross-platform (more or less). If boost were to
>an autoconf-generated config header, things would be a bit tidier
>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
>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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at