Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 11:32:04

--- In boost_at_y..., "kral123" <kral123_at_y...> wrote:
> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > I suppose we ought to make a FAQ page about this. You can find
> answers
> > by searching the yahoogroups archives for autotools, automake,
> I read through the threads and got a general feel for the Jam
> argument. It's that the boost folk are aiming to make as portable
> package as possible and want to provide everything needed in one
> package and think they can't do that with autoconf+automake, and
> autoconf+automake are too tied into UNIX or would require too much
> external code (some people seem to think they need cygwin). For
> example:
> > "The Cygwin tools are not an option for Boost. We can't require
> Win32 users to d/l this toolset just to use Boost."
> The thing is, boost _is_ requiring users to download a toolset just
> for Boost. It's a boost-specific Jam. Why not instead provide,
> like you do Jam, the open source tools required to support
> autotools? It's the same concept, but autotools-support rather
> jam-support. You can provide them in source form and have a
> just like you do now for Jam.

I think you miss the point. Jam is a very small executable, and I
don't even have to install it since I can set up a build process that
boost straps it with tools that already exist on my platform. There
is no native port of autoconf+automake that exists on my platform
(Windows), and so to use it I have to install much more then just the
autoconf/automake tools... I have to install the cygwin subsystem.
The burden is too high.

In any event, there are benefits to Jam that FAR outweigh make or any
of it's variants, so I don't think we should go backwards in any

> The benefits:
> - Has the same benefits as including the source of Jam as is done
> now, as boost will still have the minimal external dependencies as
> was desired.
> - Brings in all the benefits of being able to use autotools. (More
> portable, user + devleoper familiarity, existing platform
> compatibility tests, etc.).

Autotools isn't portable, and it's familiar only to Unix
users/developers. You're making this argument solely because it's
the tool you're familiar with. Maybe I should argue that we should
abandon the command line tools entirely and should be extending
Eclipse ( to do portable C++ development with
support for Boost. After all, Eclipse is more portable then
autoconf+automake and I'm familiar with using it.

At least with Jam the learning curve is small. Granted, Jam isn't a
solution for the autoconf half of the equation, but we honestly
haven't arrived at a need for that half of the equation yet.
> - These tools aren't boost-specific; other people support and
> these tools. It would free boost people to work on boost rather
> having to work on and maintain a custom build system for boost. As
> architectures change or emerge, you gain support for them
> automatically.

There's been a need for many years for a portable config/build
system, even for projects that use autoconf+automake that pretend to
be portable to non-Unix platforms, and yet there's still no
autoconf+automake for Windows that doesn't require cygwin or make
assumptions about the system. So my bet is that if we did adopt this
we still wouldn't get any help from these other people.

> - People that already have support for autotools wouldn't need to
> hassle with building tool support at all.
> The other confusion I'm hearing is that people think that the tools
> required to support autotools scripts require you to install all of
> cygwin, or that they will have UNIX forced on them, or that
> too many tools required. These aren't true at all. The required
> tools can compile totally without cygwin and as native Windows
> programs (using the Microsoft runtimes, and as such obviously
> supporting "C:\" paths, etc.). It's commonly known as mingw32
> support.

I've searched high and low and have found not a single port of
autoconf+automake using mingw32. Care to point one out?
> For an example, look at the toolchain created by the SDL people
> runs via mingw32 (

I don't see a native port of autoconf+automake here, and
the "recommendation" is to use the cygwin environment. In fact, the
page contains many shell scripts that can only run under cygwin.

> You'd only need
> 10% of it or so (sh, sed, + fileutils mostly) since it's a complete
> development environment for SDL and therefore has way more than
> need just to run autotools, but just for an example, it packs the
> support programs, a GNU toolchain, compiler, debugger and libraries
> into 8 megs and you can quite easily pop up a DOS window and run a
> configure script given you have the exes in your path as it
> the needed tools.

10% of cygwin is still a LOT more then I can install.

Bill Kempf

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