From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-05-26 08:34:27
I'm glad to see this thread starting, I definitely think this is a good
"David Abrahams" <dave_at_[hidden]> wrote in message
> "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.
> > 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
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
> If people prefer we could establish a separate list, but I fear there
> might be a great deal of overlap.
> Dave Abrahams
> Boost Consulting
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk