Attempt to refocus the "installing" discussion

From: Darin Adler (darin_at_[hidden])
Date: 2002-02-25 02:39:31

Here's how I understand the installing issue. This might help some people
understand the different perspectives brought by other programmers:

Programmers who use the Boost libraries want to make them available in the
standard way for the various platforms; 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.

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.

Typical Macintosh programmers don't expect to have an install process at
all. They expect to get header files and library files or source files, and
point the IDE at them.

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