Re: About installation

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 
installing
> >> 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 
BOOST_ROOT/boost
> >> 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, 
you've
> > 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 
_way_
> > beyond the bounds of reason.
> 
> Why would end users have the Boost source?
> 
> If you distribute binaries of your finished products, the end users 
won't
> 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