Re: [boost] Re: [gauging interest] Windows GUI - semi-installer

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-05-27 10:15:59

"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:BAY101-F27D3D4829B2FDF38C3BA41A00F0_at_phx.gbl...
> Robert Mathews wrote:
> >I'm glad to see this thread starting, I definitely think this is a good
> >idea.
> >
> >"David Abrahams" <dave_at_[hidden]> wrote in message
> >news:uoeay3md4.fsf_at_boost-consulting.com...
> > > Don't try to parse Jamfiles.  It will be fragile at best and a
> > > disaster at worst.  Think of Jamfile contents like C++ source code;
> > > you want a real C++ compiler in order to process that and make any
> > > sense of it.  For Jamfiles you want to do any understanding within
> > > Boost.Build.
> >
> >As far as JAM interacting with the installer program, why don't you have
> >boost.JAM build the installation program?  That way this installer isn't
a
> >red-haired bastard stepchild,  but just another target in the Boost.build
> >environment. Boost.build is certainly powerful enough!
>
> This is a good idea and something I would provide in my GUI/helper
> utilities.
>
> >Basically, I'd add a target after "install" that could grab the source
and
> >built libraries and feed those files into the installer script, creating
a
> >single installer output file (say, "boost_1.32.msi"). Then the boost
> >maintainers could publish just that file on the web.
>
> The problem is that the library files generated come to around 520Mb per
> toolset. Therefore, packaging the *.lib files becomes unrealistic
> (especially with the countless variations of gcc: is gcc-3.3 version
3.3.0,
> 3.3.1, ...?)

Did you see my other post where I addressed that? I'll paste it in here for
convenience, sorry if the duplication annoys. What do you think?

<<<<<<<pasted post follows>>>>>>>

I see from reading the other thread that there seems to be an assumption
that running the compiler on the users machine in order to install boost is
a only way to install boost, because of the size of the resulting binaries.

I'd like suggest a different model.

On my machine, the compiled libraries + source (no object files) takes 700MB
for all the models for one compiler (VC71 in this case).  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 displayed a UI
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 simple 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. If you want, I can start to enumerate all of the different ways
that the programmers in my shop manage to get it wrong, but it's a dreary
list, and I've got the advantage of being able to walk over to their
machines and poke around. Usually it's some sort of path issue, but that
doesn't make it simple to diagnose.

"Robert Mathews" <rmathews_at_[hidden]> wrote in message
news:d74j5c$7v6$1_at_sea.gmane.org...
> I'm glad to see this thread starting, I definitely think this is a good
> idea.
>
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uoeay3md4.fsf_at_boost-consulting.com...
> > "Pablo Aguilar" <pablo.aguilar_at_[hidden]> writes:
> >
> > > I believe that detecting which libraries need building would just be a
> > > matter of searching for a "build" subdirectory within a given
library's
> > > directory.
> >
> > Yep.
> >
> > > Don't know about configurations, though, maybe some simple
> > > parsing of the jamfiles would do..
> >
> > Don't try to parse Jamfiles.  It will be fragile at best and a
> > disaster at worst.  Think of Jamfile contents like C++ source code;
> > you want a real C++ compiler in order to process that and make any
> > sense of it.  For Jamfiles you want to do any understanding within
> > Boost.Build.
> >
>
>
> As far as JAM interacting with the installer program, why don't you have
> boost.JAM build the installation program?  That way this installer isn't a
> red-haired bastard stepchild,  but just another target in the Boost.build
> environment. Boost.build is certainly powerful enough!
>
> Basically, I'd add a target after "install" that could grab the source and
> built libraries and feed those files into the installer script, creating a
> single installer output file (say, "boost_1.32.msi"). Then the boost
> maintainers could publish just that file on the web.
>
> > > The reason I chose not to do it as an installer, is because I'm far
> > > more comfortable with developing GUIs with say, BCB, than I am with
> > > the installer programs I've tried.
>
> Well .. the commercial installers take care of a lot of common issues that
> occur, adding a layer of reliability and tested code for the common tasks
of
> installing files, editing paths, registry, and displaying a familar user
> interface. Are you really sure you'd want to stray off the beaten path
here?
>
>
> > >
> > > Comments, suggestions, requests are welcome.
> >
> > Making Boost easier to install is crucial.  I suggest that parties
> > interested in contributing in some way take the thread to the jamboost
> > list.
> >
> > http://www.boost.org/more/mailing_lists.htm#jamboost
> >
> > If people prefer we could establish a separate list, but I fear there
> > might be a great deal of overlap.
> >
> > -- 
> > Dave Abrahams
> > Boost Consulting
> > www.boost-consulting.com
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

>
> The installer should:
> *  extract the current Boost distribution files;
> *  setup any environment variables;
> *  build bjam;
> *  build the libraries for the selected compilers/versions, noting where
to
> install to, whether Python is supported, etc.;
> *  optionally configure your favorite IDE to find the requested headers
and
> library files.
>
> >Well .. the commercial installers take care of a lot of common issues
that
> >occur, adding a layer of reliability and tested code for the common tasks
> >of
> >installing files, editing paths, registry, and displaying a familar user
> >interface. Are you really sure you'd want to stray off the beaten path
> >here?
>
> Therefore using a commercial installer would be a good thing. The question
> is does that installer support executing command lines (to build the Boost
> files) and can you optionally process that to provide a nice UI/progress
for
> the average user who is going to be daunted by the masses of output
> generated.
>
> The alternative would be to provide Unix and Windows scripts to simplify
the
> build/install process to something like:
>
>    install-boost c:/boost-1.32 vc-7_1
>
> Reece Haston Dunn
> Software Engineer, Sophos
>
> Web: www.sophos.com
> Sophos - protecting businesses against viruses and spam
>
>
>
>
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/jamboost/
>
> <*> To unsubscribe from this group, send an email to:
>     jamboost-unsubscribe_at_[hidden]
>
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>
>
>
>