On Thu, May 22, 2008 at 8:44 AM, Doug Gregor <
doug.gregor@gmail.com> wrote:
I've spent some time improving the CMake-generated Windows binary
installer for Boost. An example of the kind of installer we can now
generate is posted here:
http://www.osl.iu.edu/~dgregor/Boost-1.35.0-vc8.exe
This actually comes from the release branch, so "1.35.0" is a bit of a
misnomer (sorry). Still, there are some cool features in this
installer that are worth checking out:
* Each Boost library that is either modular or builds library
binaries has its own installation group; you can turn on/off
installation of that library.
* You can turn on/off installation of individual library binaries
(e.g., Boost.Filesystem's "Static, multi-threaded, debug")
* Modular libraries let you turn on/off installation of library
headers. Any non-header-only library lets you turn on/off installation
of the library sources.
* Inter-library dependencies are automatically handled: try turning
off installation of the headers for the Boost.System library. You'll
see that it automatically turns off installation of the sources for
Boost.System (which can't be built without the headers), the headers
for Boost.Filesystem (which rely on the Boost.System headers), and the
sources for Boost.Filesystem (which rely on the Boost.Filesystem
headers)
* If you go through the installation process, then run the installer
again, it determines which components were installed so that you can
use this installer to add/remove components from an existing
installation.
I'm overwhelmed! This is unbelievably slick, better than a lot of software installs that have been around for years!
Possible issues:
1) Would it be better if the default install location leaf folder was "Boost-1.35.0"? I'm inclined to think so.
2) It should be possible to globally in one place set the default for what library builds (shared/static, debug/release) should be installed. I'm thinking that wanting to specify that on library by library basis is unusual, and the more libraries we add the longer and more mistake prone that gets.
3) My intuition is that four libraries (shared+static) * (debug+release) is enough choices, and more than that just gets confusing. What do others think?
If you update your Boost-CMake branch, you can build these installers
yourself. Unfortunately, it's a little harder than it should be
because the component-based installation isn't yet in CMake. So, if
you want to build these installers yourself, you need to:
1) Get NSIS from http://nsis.sourceforge.net/Download and install it
2) Get my component-based installation patch or CMake from
http://public.kitware.com/Bug/view.php?id=6847
Apply the patch to a checkout of CMake CVS and use that to build
the NSIS installer.
If you don't use my CMake patch, you'll still get a working installer,
but it won't have the cool component-based installation features.
There's more that we can do with this binary installer, e.g.,
- If we put information about each library into CMake, e.g., the
description, authors, maintainers, etc., that can be displayed when
the user's mouse hovers over that library's component in the
installer, e.g.,
The Boost.Filesystem Library
Portable facilities to query and manipulate paths, files, and
directories.
Author: Beman Dawes <e-mail address>
That would be a nice touch if it isn't too difficult.
- We can add different "installation types" that provide a
pre-selected set of components. For example, "Complete" (everything),
"Runtime" (shared libraries only), "Sources" (headers+sources), etc.
Ah! That would probably take care of issue (2) above.