RE: Directory Structure

From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-12-18 08:25:40

From: John Maddock [mailto:John_Maddock_at_[hidden]]
> True enough, but we should keep the bar as low as
> possible, unless there is some major advantage to some
> tool. BTW I have rejected free software in the past
> because it used some esoteric make/configure system that
> was unsupported on Win32.

[...]

> Let me clarify: I'm not saying that we should not have
> an integrated build/install system. I am saying that
> it should not be mandatory to use it, I would consider
> STLPort a reasonable example here - single developers
> can work with the source tree "as is" - alternatively
> the whole thing can be built and installed reasonably
> painlessly (OK I admit that the gcc makefiles have no
> install step, mainly to keep them portable I would guess).
>
> >Boost should *not* limit itself to the idea of
> >single-user installations.
>
> No, I don't believe that we do, we just need an install
> script for the current structure.

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.

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!

Paul.