Re: Attempt to refocus the "installing" discussion

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-02-25 16:37:26

  To readers who are pro-autotools:  Yes, in this posting I have
placed words in your mouths.  I have interpreted the pro-autotools
side of this discussion beyond the level of paraphrasing/quoting
existing text from the pro-autotools postings.  At first my wording of
the pro-autotools side of this discussion might look unfamiliar even
to the pro-autotools people.  I ask all parties to read this posting
in its entirety before crafting a reply.

--- In boost_at_y..., Darin Adler <darin_at_b...> wrote:
> Here's how I understand the installing issue. This might help some
people
> understand the different perspectives brought by other programmers:

  I agree that a refocusing/resummarization is good, but I think that
the pro-autotools viewpoint has not been fully represented.  Darin
Adler's posting is on-the-mark, but missing one component.

  In general I personally support more the Jam/Boost.Build side of
this discussion because Boost's innovators must have a minimalist
lingua franca with which to speak to each other which crosses all
operating systems.  But I do see that the pro-autotools side has
several valid points which are rarely seen on a large scale outside of
an entirely source-code distribution culture such as GNU/Linux (and
its extrapolations into other operating systems: e.g., cygwin,
mingw32).

> Programmers who use the Boost libraries want to make them available

  I think that (at least a portion of) the pro-autotools side of this
discussion would dispute this wording.  The pro-autotools
GNU/Linux-school-of-thought open-source community would say that the
authors of an open-source application does not redistribute the
components on which they depend.  Each Boost library (or the whole
Boost library-set) would be such subordinate components which
higher-layers of software do not redistribute.  Instead, the installer
of an GNU/Linux-school-of-thought open-source application who is
building from source (instead of installing from binary RPM/etc) must
provide the appropriate revision of each subordinate component,
including Boost libraries.  Thus to accomodate this school-of-thought,
"programmers ... make [Boost libraries] available" must be changed,
because in this school-of-thought Boost.org makes Boost libraries
available and GNU/Linux open-source programmers do not.

> in the
> standard way for the various platforms;

  I think that (at least a portion of) the pro-autotools side of this
discussion would dispute this wording.  The "the standard" implies an
official normative location.  The "for ... platform" implies that
there is one normative location promulgated by the authors of that
platform (where "platform" is operating system, compiler, or both
together).  A portion of what I think that the pro-autotools side of
this dicussion is asking for is not an official normative directory
determined by Linus Torvalds [Linux] or by Richard Stallman
[GNU/FSF/etc], but rather for a *consistent* default directory
determined by Boost.org's own choosing which could very well be, say,
/var/Boost [consistent but novel] or /usr/share/Boost [consistent but
novel] instead of /usr/include [standard for platform and unchanging].

> because they are called "libraries"
> people often think of them the way they would shared libraries or
system
> libraries. This typically involves putting the headers in a standard
place
> like /usr/include, and compiling and linking the code into one or
more
> shared or non-shared libraries and installing those in a standard
place like
> /usr/lib.

  Once mistakenly on the /usr/include line-of-thinking, deductive
reasoning which is incongruent to the pro-autotools school-of-thought
can occur.  Such deductive reasoning is quite likely to not be wrong
(i.e., factually malformed or logically misdeduced), but rather that
the pro-autotools side of the discussion would consider it as
tangential or nongermane.

> Typical Unix programmers expect to do this by typing something like
"cd
> <where-boost-is>; configure && make && make install", and further,
they
> expect the configure script to take various options to let them
customize
> the directories involved. Because of this, Unix programmers are
likely to be
> unhappy with a system that doesn't involve a configure script, a
configure
> script that doesn't take the parameters that the configure scripts
generated
> by autoconf do, or a build or install process that you can't
trigger by
> running "make" from the command line.
> 
> This is one of reasons people are saying, "Using Jam for your build
system
> is crazy." Not that I agree, but it helps to understand this.

  I think that the pro-autotools side of this discussion would say
that this *convenience* for the (relatively) few GNU/Linux-open-source
application-*developers* [called: the build-to-develop case] is only a
portion of their argument.  (Some might even say that this
*convenience* alone is a trivial portion of their argument.)  But I
think that the stronger portion of their argument is that this
consistent-one-liner installation is not a matter of mere trivial
syntactic convenience, but rather is a required key axiom of the
entire GNU/Linux-open-source *source-code distribution*
school-of-thought for the (relatively) numerous
*installers*-from-source (who are downstream from the
application-developer) who do not want to even look at line of source
code, and who definitely are not interested in modifying/extending the
application software.  Such installers of software X are not the
developers of X.  Such installers are interested only in bringing the
source distribution to their peculiar platform (where platform for
Linux would be the set: CPU-architecture, kernel revision) for the
sole purpose of using the software [called: the build-to-execute
case].  If the installer's platform was not "peculiar", the installer
may very well have chosen a binary distribution mechanism, such as a
binary RPM, instead of installation via building-from-source. 
Installation via building(-to-execute) from source-code is a key axiom
in the GNU/Linux open-source culture.

> Typical Macintosh programmers don't expect to have an install
process at
> all.

  I think that the pro-autotools side of this discussion would say
that  is because Mac platform does not have a GNU/Linux-style
institutionalized open-source *source-code* distribution culture
in-grained into at every level.  Indeed (with the exception of
periodic incompatibilies/road-bumps: 680X0 to PowerPC, preOSX to OSX)
Mac software rarely (if ever) needs the build-to-execute kind of
installation for software.  Library source-code distribution for Mac
would be almost entirely build-to-develop (or even nonsource-code
distribution: headers with prebuilt libraries).

> They expect to get header files and library files or source files,
and
> point the IDE at them.

  Because 1) build-to-execute is completely absent from the Mac
culture, because 2) build-to-develop is nonessential in the Mac
culture, and because 3) header-and-binary distribution is the minimum
expected in the Mac culture, Mac programmers do not have the same
expectation that the pro-autotools build-for-execution
school-of-thought requires.  Thus, I think that the pro-autotools side
of this discussion would consider the Mac analogy is tangential or
nongermane.

  I think the pro-autotools side of this discussion would consider the
fundamental core issue to be: the build-to-execute case.  In other
words, forget about the developer for a moment.  Indeed forget all
operating-systems where the culture does not rely on source-code
distribution and does not rely on build-to-execute (i.e., forget all
operating systems other than GNU/Linux, FreeBSD, and the like). 
Consider for a moment the *other* nondeveloper user of Boost.  With
the GNU/Linux source-code-distribution school-of-thought, there is
another entirely separate category of library user: the person who
wants to *execute* an application, who has only source-code, and who
needs to build for the sole purpose of transforming unmodified
source-code to unmodifed executable.

  Nearly all of the Jam/Boost.Build side of this discussion have been
focusing on the developer who is squarely in the build-to-develop
case.  In quite a few postings people who subscribe to the
pro-autotools school-of-thought mention the build-to-execute case or
focus entirely on the build-to-execute case.

  To enable the build-to-execute case, a consistent directory to which
Boost is installed is not merely nice, but required for one or more
higher layers of software in the same executable to use Boost without
manually modifying/tweaking any build/install file.  This consistent
default directory *must* be specified by some central authority
(otherwise different authorities may---i.e., will---choose different
default directories).

  To show the lack of scalability of the "each programmer/installer
should put Boost where he/she sees fit" work-around to Boost not
having a default directory to which it is installed for
build-to-execute cultures such as GNU/Linux, let us assume 1000
GNU/Linux-open-source application-developers each (alone) write a
different application which is distributed via source-code-only
distribution.  Let us asssume that Fred wants to run all 1000 of these
applications on his computer with an Alpha CPU.  Fred's Alpha computer
is peculiar enough that the popular precompiled binary RPMs (e.g., for
Intel/AMD x86) will do him no good.  Fred falls squarely into the
build-to-execute category.  Because Fred would receiving 1000
different source RPMs to build(-to-execute) which are written by 1000
different developers, Fred might have as many as 1000 build/install
scripts to tweak (which he is quite loathe to do).

  To show the ramifications of the "each programmer should ship the
version of Boost which they used to write their software" work-around,
let us assume that an application-developer for a GNU/Linux
application Foo uses at least two nontemplate libraries X and Y, where
X and Y each in-turn use Boost and where X and Y are each distributed
(separately) in source-code form.  The X library developer has shipped
Boost 1.27 in a particular directory which has been made known to
autotools.  The Y library developer has shipped Boost 1.19 in a
different directory which has been made known to autotools.  Foo's
developer may experience at least link-time conflicts from the two
different revisions of Boost.  Foo's developer may even experience
compile-time conflicts from the two different revisions of Boost if
the same Boost headers were #included from X's headers and Y's headers
and thus the same compilation unit in Foo (but not in X, not in Y, and
not in Boost) may be exposed to conflicting declarations coming from
the two different Boost revisions.

  Because Jam/Boost.Build appear to not currently satisfy this
build-to-execute case (but rather focus entirely on the
build-to-develop case), there appears to be room for a healthy
discussion of this topic, where each side (Jam/Boost.Build versus
autotools) has something valuable to communicate to the other. 
Indeed, I think that (at least some people on) the pro-autotools side
of this dicussion would consider Boost's lack of addressing the
source-code distribution topics of the build-to-execute case, Boost is
not being ecumenical as is desired later in Darin's posting.  Because
of this lack, they might claim that Boost is hostile to the
build-to-execute installation axiom on which the entire GNU/Linux
culture is based.

> Typical Windows programmers might expect one of the above, or they
might
> expect to run some kind of installer that puts header files and
libraries in
> the right directories. But unlike on Unix, those directories are
probably
> specific to the development system. (I probably got this wrong,
because I
> haven't done enough Windows programming to know how things work or
to feel
> empathy for typical Windows programmers.)
> 
> Any of the installation techniques that put the libraries into a
standard
> place like "/usr/include" without a versioning system could be a
problem for
> Boost, since we change things between Boost releases in a way that
makes it
> unlikely you can upgrade Boost and still expect all the programs
using it to
> continue to compile. So you'd have to update every single program
on a
> computer if you want to compile them. Similarly, making shared
libraries
> that are not carefully versioned is probably a mistake for the same
reason.
> 
> On Unix, where installing such things in a global place is a way of
life, we
> might need some kind of standard way of handling this. For example,
in the
> Gnome project, there's a whole complex system where the headers
don't
> actually go into /usr/include, and instead, programs that use the
library
> run a command to generate the appropriate "-I" commands to make the
library
> get picked up from where it "really" is.
> 
> As someone who loves the Macintosh style and loves IDEs, I'm
comfortable
> just ignoring the build and install system. I think the simplest way
to use
> Boost is to add it to your program as if it was part of the source
code, and
> not try to "install" it at all. But without an IDE, that can be a
pain, I
> guess.
> 
> It seems like the issues aren't simple, and it would be great if
Boost could
> stay as "ecumenical" as possible. Maybe we need to look at a
particular
> successful example like STLport and imitate what they do rather than
> inventing something original.
> 
>     -- Darin