[boost] Re: Re: Re: Customer Friendlier Boost Installation

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-05-26 09:06:23

"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:BAY101-F51E45E48EC4EA585C0E9EA00E0_at_phx.gbl...
> Robert Mathews wrote:
> >I've been following this thread for a bit.
> >
> >I think that the boost community would do well to do the following:
> >- precompile boost for Windows compilers
> >- package up the headers and .libs in a MSI installation script (or some
> >other native windows installer)
> >- provide that for download
>
> The problem is that each compiler adds several hundred megabites to the
> install, so supporting VC6 (which patched version?), VC7, VC71, VC8 (which
> beta/CTP?), BCB5, BCB6, CodeWarrior 8.x/9.x, gcc (which version??) you
will
> end up with an install that is on several DVDs!!!

On my machine, the compiled libraries + source (no object files) takes 700MB
for all the models for VC71.  But, that's uncompressed. Compressed is a
different story.

When I compress my directory, I get a 90% reduction in size - more like
70MB. But that's still too large. However, a single compile model - ie,
single threaded (debug+release) - takes only 4.6MB, which is easily
downloadable.

And all programming shops I've been to pick a particular compiler,
programming model, and then stick with it, so the following idea should
work:

So, what you'd do it is write a installer stub that
1) queried for compiler model
2) queried for compile model (single threaded, multithreaded, static, dll
etc)

And then took that information and went off and downloaded the correct
library.

Seems simply enough to me. Much simpler than trying to recreate the UNIX
auto-config behaviour on Windows, because Windows just isn't very robust
that way.

>
> The easiest way would be to have the installer auto-detect compilers on
your
> machine and allow the user to edit the list, adding/modifying compilers as
> they need, then select which ones they want to build the libraries for. It
> should be possible to build again at a later stage when you add a new
> compiler, etc.

That's precisely not the easy thing. It saves download time, but costs
complexity, and worse, when things fail, they fail far away from the expert
who constructed the auto-detect algorithm.  So, you end out with a
frustrated expert and a frustrated user.

It's the customer support issue. You want to mimimize the complexity of what
executes on the client, so that less can go wrong.

>
> Granted, this could make the install take a long time (if you are
supporting
> many different compilers), but the user should be able to (optionally) see
> the output and provide a way of estimating how long the build phase will
> take (so the user knows that they can come back in an hour or whatever).
>
> An installer like ths could be intelligent enough to extract and/or build
> only the ilbraries you want, for example, you could just build the
> Filesystem library.
>
> >That way we sidestep the whole issue of using JAM. This has two benefits:
> >- Windows programmers expect to be able to click on a link and simply
> >download the answer.
> >- Windows programmers would get a reliable library that was built under
> >controlled circumstances. We'd all spend less time supporting folks who
> >have
> >trouble driving the compiler via JAM, and/or who have somehow produced a
> >corrupt boost library.
>
> What if you install a library for VC6.5 and you only have VC6.0? Building
a
> project could then break when you link against the 6.5 versions.
>
> >Personally, I did use JAM successfully, but I also encountered a number
of
> >error messages that I quickly worked through, and didn't think much
about.
> >It would have been a barrier to someone less experienced though, and we
> >don't want that.
>
> The install/build GUI could process this so that it generates a friendlier
> summary informing you of what broke.
>
> Reece Haston Dunn
> Software Engineer, Sophos
>
> Web: www.sophos.com
> Sophos - protecting businesses against viruses and spam
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>