|
|
Boost Interest : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-05-22 11:26:18
On Thu, May 22, 2008 at 8:44 AM, Doug Gregor <doug.gregor_at_[hidden]> 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.
Thanks for all your work on this!
--Beman