Re: Attempt to refocus the "installing" discussion

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-02-25 19:48:26

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:37 PM 2/25/2002, danl_miller wrote:
> 
>  >  To readers who are pro-autotools...
> 
> Danl, please don't cast discussion as "pro-" some tool, or the
implied
> "anti-" some tool.

  I think that in numerous postings, there as been a quite clear
advocacy of autotools by certain authors in certain contexts and a
quite clear defense of Boost.Build in (what I believe to be) certain
(other/separate/distinct) contexts.

  Please re-read my posting in its entirety and I think you will
clearly see that I am not "anti" any tool.  I do not subscribe to the
hypothesis that the existence of a person who advocates X implies that
that same person is against all competitors of X.  Co-existence is an
alternative to fight-to-the-death competition.  Evolution of solutions
into separate niche environments is an alternative to territorial
disputes in the same niche.  If you read the entirety of my posting, I
think that the message is quite clear that Boost must be both
pro-Boost.Build and pro-autotools for different reasons in different
contexts/niches (without the concept of "anti" in any way).  The two
niches are: 1) build-to-develop (especially
build-to-develop-Boost-itself) versus 2) build-to-execute.

> Developers (and/or their employers) choose the tools they find most 
> suitable for their own use.  They aren't idiots (at least the
developers; 
> sometimes you wonder about the employers).  They know their own
needs.  We 
> don't know their needs as well as they do.

  Likewise, please don't cast the discussion as "we"/"us" versus
"they"/"them".  Each side has something to teach each other.  My hope
is that each side will learn the subtleties of each other's position
to the point that each alleged "side" realizes that there really isn't
two sides at all, but rather two different contexts/niches.

  What is each side trying to teach the other?

  The advocates of autotools are trying to teach the advocates of
Boost.Build that the claimed Boost ecumenicalism has to some degree
broken down in the GNU/Linux source-distribution culture.  By focusing
on build-to-develop(-Boost-itself), Boost has undermined
build-to-execute in source-code-centric software-distribution
cultures.

  The advocates of Boost.Build are trying to teach the advocates of
autotools that the official internal business of Boost invention &
development & submission needs a build environment which is not
UNIX/POSIX.1-centric or UNIX/POSIX.1-dominant.

> Be happy there are diverse tools available.
>  It doesn't help to get upset 
> if someone chooses different tools than you might choose.

  Please re-read my posting in its entirety.  My posting summarizes &
strongly defends & celebrates the positive autotools-advocacy points
that I have harvested by reading all of the postings from autotools
advocates.  My posting attempts to debunk the (mis)perception of
head-to-head competition between Boost.Build and autotools.  (They are
two ships passing in the night; they need not fire weaponry at each
other.)  My posting attempts to show that Boost.Build is focused on
what Boost contributors/submitters need to accomplish
build-to-develop(-Boost) whereas autotools is focused on what
source-code-distributing cultures---such as GNU/Linux---need to
accomplish build-to-execute.  (As a by-product, the autotools approach
which permits build-to-execute in source-code-distributing cultures
such as GNU/Linux can be leveraged unchanged for
build-to-develop[-nonBoost-software] in those source-code
software-distribution cultures.)

  Instead of focusing on "pro" versus "anti" and "we" versus "they",
if we yearn for two topics in opposition to compare & contrast,
please:
  1) focus on 1A) "build-to-*develop*(-Boost-itself)" [i.e.,
Boost.Build for conducting Boost.org's business] versus 1B)
"build-to-*execute*" [i.e., autotools for source-code-centric
software-distribution cultures] and
  2) focus on 2A) "*developers* of GNU/Linux nonBoost layers of
software (e.g. applications, higher-layer libraries)" versus 2B)
"*installers*/nondevelopers of GNU/Linux executables/applications". 
(or FreeBSD or any other source-code-centric software-distribution
culture)

  If "build-to-develop" and "build-to-execute" are imperfect terms,
alternative word-choices exist: build-to-modify versus
build-to-deploy, respectively.

>  At Boost we try 
> to work with them all to the extent volunteers are willing to
contribute.
> 
> --Beman