From: Peter (pjfoley_at_[hidden])
Date: 2005-05-26 18:43:21
I recommend looking here: http://sourceforge.net/projects/wix/
"The Windows Installer XML (WiX) is a toolset that builds Windows
installation packages from XML source code. The toolset supports a command
line environment that developers may integrate into their build processes to
build MSI and MSM setup packages "
Theroeticially you could build a simple C++ application that could generate
the XML file which includes dependencies between libraries and then create
MSM setup packages. Then you could chop and choose what you would like to
A really good tutorial is here: http://www.tramontana.co.hu/wix/
Taken from the tutorial introduction:
The toolset we are about to introduce, WiX, uses a different approach.
Instead of a tool with a graphical interface that allows the developers to
collect the files and other related tasks making up the installation process
manually, it is much more like a programming language. Integrating perfectly
with the usual process of creating applications, it uses a text file (based
on the increasingly popular XML format) to describe all the elements of the
installation process. The toolset has a compiler and a linker that will
create the setup program just like our usual compiler creates our
application from the source files. Therefore, WiX can be made part of any
automated application build process very easily, be that based either on the
classical technology of makefiles or the similar features of contemporary
integrated development environments.
In addition to this integration, providing basically nothing more but
developer comfort, WiX offers another level of integration, far more
advantageous than the first one: the integration of the setup development
process with that of the application. Traditionally, setup programs were
only written when the main application had already been finished; often even
by different developers. This approach requires a tedious and error prone
process of collecting information about all the resources making up the
application. While the files themselves are usually obvious, registry
entries, services and most forms of inter-resource dependencies are often
hard to reconstruct in a later stage: if solid development documentation is
lacking, the setup developers have to collect all pieces of information from
the original developers or try to extract it from the source code.
In an integrated application/setup development environment, the original
developer should modify the WiX source files in sync with the application
development. As soon as a new module has been started, a new registry,
service or other dependency has been coded, the appropriate setup
modification should be made in parallel. Using this approach, no important
information will ever be lost and, as a bonus, the setup program will be
practically finished together with application itself.
The for a blog with the original developer is here:
----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
Sent: Friday, May 27, 2005 12:21 AM
Subject: Re: Customer Friendlier Boost Installation
> "David Bergman" <davidb_at_[hidden]> writes:
> Well, to begin with I think we need a Windows installer for headers
> and vc7.1 binaries. There are some free pro-quality installer
> construction systems for Windows out there; I forget the names though.
> There are a number of valuable possible enhancements I can think of,
> if you're ambitious:
> - Allow users to select which libraries they want and:
> a. use bcp to allow users to cut down how much is actually
> installed, or
> b. allow people to cut down how much is actually downloaded (a
> la cygwin installer)
> - Add support for binaries for other compilers, although especially
> when you add STLPort in as a variable there are just too many
> libs to build to get complete coverage, so:
> - add support for invoking bjam via a GUI. Preferably this GUI
> would dynamically show the user the bjam command-line it is
> composing so that the user would gain some familiarity and be
> able to step outside the bounds of the GUI eventually.
> > I would like for us to have an installer-generator (for Windows) so
> > we do not have to recreate, or at least rebuild, the installer for
> > every revision of Boost.
> Sounds good. Thanks for volunteering!
> 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