|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-05-27 10:51:36
on Tue May 27 2008, "Doug Gregor" <doug.gregor-AT-gmail.com> wrote:
> 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.
Can you explain what you mean by "cache entries?"
>> (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.
This part is not a big problem, since they have lots of mirrors. The
system can always switch mirrors when SF breaks. At BoostPro we provide
a fallback mirror in case SF can't help us. We could do the same at
OSL for Boost.
>> 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.
Why is downloading from mirrors incompatible with daily snapshots?
-- Dave Abrahams BoostPro Computing http://www.boostpro.com