Re: Why Jam?

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-02-21 10:56:04

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "kral123" <kral123_at_y...>
> 
> >
> > I think you might be confused about what autoconf really is. 
There
> > are jam's configuration scripts and autotools' produced
> > configuration scripts.  Both are scripts that need to be
interpreted.
> 
> I think you might be confused about the aims of Boost.Build. We're
primarily
> focused on providing a development/testing system for Boost
developers.
> Think of it as a text-based IDE. We /think/ that these jobs are the
hardest
> ones, and if we do them right, handling installation/deployment
will be
> relatively easy. We're hoping to do a good job in that department,
too, but
> so far it hasn't been a priority. The fact that Boost is gaining
users so
> rapidly may mean that installation/deployment should be a higher
priority
> than it has been so far.
> 
> -Dave

  I have been thinking along a parallel line while reading all
postings in this thread.  The current Jam-based Boost.Build is for
Boost developers-contributors.  Many of the anti-Jam postings (and not
fully-in-favor-of-Jam postings) have been focused on
installation/deployment.

  I recommend tolerating both in different contexts.  The set of Boost
developers who actively contribute code is a much smaller group than
the set of people who install/deploy Boost without contributing any
code to the Boost libraries (other than possibly occasional
bug-fixes).

  1) All Boost contributors would need to speak the lingua franca of
Jam with each other.  (To erode Jam as the lingua franca among Boost
developers-contributors would be very unfortunate erosion to a strong
feeling of community which has demonstrated that it can produce very
good work.)

  2) Conversely, the people who advocate make, automake, and autoconf
for installation/deployement reasons can optionally maintain that
build infrastructure separately/derivatively.

  THE PROPOSED RULES: No contribution to Boost would be accepted
without properly-working jamfiles which meet the expectations of the
Boost community.  No contribution to Boost would be accepted if only
make, automake, and autoconf were provided.  No contribution to Boost
would be *required* to have the necessary files to support make,
automake, and autoconf.  Any contribution to Boost (which itself is a
kind gift) may optionally elect to contribute an extra gift of files
to support make, automake, and autoconf, but by explicit policy, there
would be no pressure nor brow-beating for the official-Jam-only
developer-contributor to also provide files to support make, automake,
and autoconf.  When a contribution is made to Boost which is Jam-only,
the community of make/automake/autoconf volunteers would simply kindly
note that they have some maintenance to do to their
make/automake/autoconf deliverable which they themselves alone are
advocating.

  Specifically I recommend that people put their own action where
their own preferences/convictions are.  I myself prefer to obediently
use the official Jam-based Boost.Build which the community provides
for me and thus I will put my own action into using Jam and expanding
the official Boost jamfiles when contributing a new library to the
Boost libraries.  But other people who advocate make, automake, and
autoconf for installation/deployment reasons should build out
something like a Boost.Autoconf so that Boost is more popular in
development communities (e.g., the GNU/Linux open-source movement)
which expect make, automake, and autoconf.  Likewise, still other
people who advocate some other development/portability environment or
IDE (e.g., Eclipse, Microsoft's school-of-thought du jour, or yet
another autoconf competitor) can elect to build out their own
build/install/portability files.  By official policy the
Boost.Autoconf would be an elective adjunct---*not* a
*competitor*---to Boost.Build.  The same would be true for any
Boost.Eclipse or any other analogous adjunct build/install/portability
environment.

  Each adunct community of build/install/portability-environment
advocates which contributes a build/install/portability file-set to
Boost would maintain an adjunct WWW-page on the http://www.boost.org
WWW-site listing for which libraries (CVS tags, releases, etc) their
build-environment file-set has been built out and whether that build
is successful or not.  Obviously, the Boost community at large already
does this for Jam and would continue doing so only for Jam.  Each
adjunct build/install/portability-environment advocacy group would
take on the responsibility of both maintenance of their environment of
advocacy as well as the testing of their environment of advocacy.  For
logistical reasons, maybe these adjunct does-it-build WWW-pages would
not be housed at http://www.boost.org but rather accessible via a link
from http://www.boost.org to the adjunct community's own WWW-site

  This proposed solution:
  1) would be the best of both worlds (good for the community of
Boost/Jam contributors and good for the
make/automake/autoconf/GNU/Linux community),
  2) would recognize that the Boost developer community has different
subgroups (e.g., contributors versus users/installers/deployers who
like to shape the design & thus participate in the Boost developer
community instead of merely the Boost user community), and
  3) would recognize that Boost will become more successful if
accepted by the open-source community at large (where the GNU/Linux
community is a nontrivial subset of the open-source community whose
shunning would be unfortunate if based solely on a build-time hurdle).

  The focus here in Boost should be on C++-file content, not on build
environments.  Any focus on build environments should be focused on
removing hurdles.  One hurdle is how do the widely-spread community of
Boost contributors-developers speak to each other with a lingua
franca, despite POSIX/UNIX versus Microsoft versus Mac differences. 
Another hurdle is how does Boost get out to all of the C++ developers
who are intended to install & use Boost libraries.  The goal here in
Boost should be to design well-thought-out useful C++ library content
which are popular with the C++ community, so popular that they become
incorporated into the C++ standard and incorporated into numerous C++
programs/applications/embedded-systems.  If a build-time hurdle is
eroding either this focus or this goal, then let's figure out a
work-around to that hurdle.  This posting presents one such
proposed work-around.