Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-26 07:33:13

--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 2/25/02 6:17 PM, Ross Smith at r-smith_at_i... wrote:
> > Daryle Walker wrote:
> >>
> >> I've seen a lot of messages about using autoconf or jam for
> >> Boost. I wonder if these people are making the issue more
complicated than
> >> it is. Remember that some of us (like pre-X Mac users) use
Boost without
> >> Jam, we just resolve the build issues manually. It's not that
hard, just:
> >>
> >> 1. Expand the Boost archive somewhere
> >> 2. Have your makefile or project file point to the
> >> directory as part of its search for (system) header files.
> >> 3. For mandatory source files, add those individually to your
project file
> >> or makefile.
> >
> > <sigh> And despite any number of us explaining in great detail,
> > succeeded in completely missing the point.
> >
> > The problem is not installation by developers. That's awkward but
> > workable now. The problem is installation by END USERS who
wouldn't know
> > an include path from a hole in the ground. Expecting users of our
> > software to go through anything as complicated as the above is
> > beyond the bounds of reason.
> Why would end users have the Boost source?
> If you distribute binaries of your finished products, the end users
> see the code.

This is the problem that the autotools folks have been trying to
point out. For Mac and Windows there's basically one stable
environment (well, there's more then one for Windows, but the
differences between them are minimal and easily handled by OS
detection in the code), so distribution of binaries is possible, and
actually preferred. For the *nix crowd there isn't a single stable
environment. Even the same distribution of Linux (say, redhat) may
have numerous parts that have been updated/changed/tweaked/etc. by
the user, and attempts to distribute binaries often results in broken
installations. So, they are used to distributing source instead, and
an "installation" includes the process of compiling the source to
binary form and placing the "pieces" in the proper locations.

The current state of Boost deployment/maintenance is a little
adversarial to this form of distribution. The problem is, we have
compelling reasons to not adopt everything required to make
Boost "play nice" in such a world. So the only solution (and it
should be workable) is for the *nix folks to provide their own
autotools installation scripts and to somehow manage/track/deploy
specific versions of Boost. This requires work, and is an imperfect
solution, but the only one that's currently compatible with the needs
of the Boost developers.

Some day I hope there's a full solution to the
configuration/deployment issue, since everyone would benefit from it,
including Windows/Mac developers. But we need a simple solution that
has minimal burden on the Boost developers/contributers.
> If you are doing an open-source thing, then you would need to
include Boost
> source. Couldn't you just keep a private copy of the version of
Boost you
> used with the rest of your source? That will protect you from an
end user
> having a different version of Boost that breaks your code. I don't
know if
> this is proper, but you could strip everything out of the private
Boost copy
> except for the BOOST_ROOT/boost directory (and the various
mandatory source
> files all over the BOOST_ROOT/libs/* directories [Hmm, another
argument for
> having an unified mandatory source directory.]).

There are actually several solutions to management of Boost
versions. For instance, the open source project could include
scripts that pull the proper version of Boost out of CVS and
configure/build/install that version. This eliminates the need to
maintain seperate archives of the Boost source.
Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at