[boost] Re: Installing Boost Libraries

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-23 19:35:22

In reply to messages from Braden N. McDaniel and Jens Maurer:

Jens:
>In general, we should take care that the
>user's build requires only the most basic tools available on
>all platforms (on Unix, Bourne shell and make, on Windows
>command.com and the tools delivered with the compiler).

Yes. Anything not normally available on the platform would have to be
included in the boost distribution, and that gets very unwieldy.

Braden:
>GNU autoconf/automake/libtool cover a pretty broad range of
platforms. Not
>Mac (though I think there's a good deal of hope for OS X support in
the
>future), and Windows support is limited to Cygwin. The GNU tools are
>well-suited to the various Unices, where pre-compiled binaries
probably
>aren't required. However, specialized installers for Mac and Windows
>(which very well may include pre-compiled binaries) are probably
called
>for.

Would something like this work?

Add a directory to the distribution, say libs/src, which contains all
the .cpp files which go into building a boost binary library.

Add a directory, say libs/build which contains nothing except
sub-directories (and maybe an index.html file containing links to the
sub-directories).

Each sub-directory represents a platform, and holds an index.html
(the modern version of readme.txt), plus whatever scripts, batch
files, or magic is required to build a boost binary library for that
platform.  The scripts don't have the source files wired into them,
they just build whatever is in libs/src.  The output goes into the
current directory so multiple builds can coexist.

Platforms can overlap; there might be an GNUautoUnix directory that
tries to build for any Unix platform and another directory with
builds for some specific Unix.

For Windows, it would probably be best to add one more level to the
hierarchy; libs/build/win/gcc, libs/build/win/vc, libs/build/win/bcc,
libs/build/win/mw, and so on.

While some scripts for some platforms might be sophisticated, the
objective is just to build the library from scratch, so full
make-like facilities aren't required.

Comments?  Is the above at least headed in the right direction?

--Beman