Re: Why Jam?

From: kral123 (kral123_at_[hidden])
Date: 2002-02-20 10:59:17

--- 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 the 
answers
> by searching the yahoogroups archives for autotools, automake, etc.

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 a 
package as possible and want to provide everything needed in one 
package and think they can't do that with autoconf+automake, and that 
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, just 
like you do Jam, the open source tools required to support 
autotools?  It's the same concept, but autotools-support rather than 
jam-support.  You can provide them in source form and have a Makefile 
just like you do now for Jam.

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.).

- These tools aren't boost-specific; other people support and develop 
these tools.  It would free boost people to work on boost rather than 
having to work on and maintain a custom build system for boost.  As 
architectures change or emerge, you gain support for them 
automatically.

- 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 there're 
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.

For an example, look at the toolchain created by the SDL people that 
runs via mingw32 (http://www.libsdl.org/Xmingw32/).  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 you'd 
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 provides 
the needed tools.