Re: Why Jam?

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

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

> 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 (http://www.eclipse.org) 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 
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.

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

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 
that 
> runs via mingw32 (http://www.libsdl.org/Xmingw32/).

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

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

Bill Kempf