Why are we discussing this? (was: Re: Directory Structure)

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-12-19 12:04:29

on 12/18/00 1:25 PM, Paul Moore at paul.moore_at_[hidden] wrote:

[SNIP]
> It seems to me that we are in danger of confusing two issues - build and
> install.
> 
> In my view, there is *no* install system which can adequately handle all
> possible variations of what people could do in terms of include directories,
> library locations, etc. Particularly on Windows, where there is no
> strongly-established convention as there is on Unix. (And where the nearest
> thing to a convention includes directory names with spaces in :-()
> 
> While I do not object to the concept of an install system, I believe that
> ultimately, the install problem is trivial:
> 
> 1. There is a boost/... directory containing headers. Put it somewhere.
> 2. There are some (possibly none) boost library files. Put them somewhere.
> 3. Tell the compiler where these things are, either as a one-off compiler
> configuration change, or each time you run a compile.
> 
> In my personal experience, automated installation processes tend to obscure
> the triviality of this routine. Have you never installed a package with a
> big installer script (or installer exe on Windows), and not been *quite*
> sure that there isn't something subtle that you need to do, in addition to
> the simple "unpack the archive" step that you think is everything? Add to
> this the fact that on Windows, uninstall processes are notorious for not
> doing the whole job, and you reach a point where you don't trust installers
> at all. I have, in the past, rejected software precisely *because* it comes
> as an installer package, and doesn't offer a "do it by hand" option.

I wanted to respond to this branch of the thread, but didn't know how.  But
Paul's response is close to some of the stuff I thought of to help me
respond.

Yes, the installation procedure for Boost is so simple that any automated
install procedure is overkill.  And any possible exceptions would be so
unusual that we shouldn't bother trying to anticipate them.  As long as we
can clearly describe where the files are, we should assume that the user is
competent enough to use their compiler system with third-party APIs.  (A
current problem is that the policy on mandatory *.cpp files isn't clear.)

> A build system (a means of generating the library files noted in (2) above)
> is a different matter. Makefiles for the Windows/Mac compilers (where there
> is little diversity in base platform functionality) and
> autoconf/configure-style scripts for Unix seem fairly reasonable. But keep
> it separate from the install issues!

I don't think we need to do any build stuff either.  Boost is mostly
template stuff in header files; there is so little concrete stuff that it's
pointless to make a library (binary) for it.  We could continue to assume
that the user is competent enough to handle using a source-code-only library
in his or her projects.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com