|
|
Boost Interest : |
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-05-27 10:19:00
On Tue, May 27, 2008 at 9:53 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Mon, May 26, 2008 at 2:48 PM, David Abrahams <dave_at_[hidden]> wrote:
>> It does some important and
>> useful things that the CMake-generated installers do not (yet). Most
>> notable among them, all the binaries are downloaded on demand from
>> SourceForge mirrors, and the interface for selecting libraries and
>> toolsets is both intuitive and flexible. Daniel Wallin did some killer
>> work to make that happen, and it should be incorporated in our CMake
>> process.
>
> Good, but I hope this is all stuff that will be maintained by the CPack
> folks, not by Boost. The other issue I'm very concerned about is robustness
> and reliability. From the standpoint of release manager, it is really
> essential that (1) the installer doesn't require hand configuration before
> every release,
It won't require any hand-configuration. There is an easy way to
automate the configuration process by giving CMake a pre-populated
list of cache entries that drive the configuration.
> (2) it can be tested automatically as part of the daily
> release snapshot process,
Sure. As you've noted, that's a little harder if we're downloading
binaries on-the-fly as part of the installation. Right now, it's easy
to do this because the installers are standalone executables.
(Unfortunately, they're also *large* executables, and most users only
need part of what's in there).
> and (3) it copes with problems like a SourceForge
> mirror being unresponsive. Using SourceForge mirrors doesn't seem compatible
> with daily snapshots, by the way.
This last bit is a little tricky, because we will be dependent on NSIS
to do the actual downloads. I don't know how robust it is, but any
fixes would have to go into NSIS itself.
- Doug