[boost] Re: [Windows MSI Installer] - Using WIX

From: Peter Foley (pjfoley_at_[hidden])
Date: 2005-05-27 09:36:47

Hi David,

Comments inline.

"David Abrahams" <dave_at_[hidden]> wrote in message
news:<ufyw9c5qm.fsf_at_[hidden]>...
> "Peter Foley" <pjfoley_at_[hidden]> writes:
 
[SNIP ...]  

> > *    Install boost using an installer application
> > *    Detect necessary installation information
> > *    Provide "header only install" or header and lib file install"
> > *    Install foo library and dependencies and that is it
> > *    Configure various IDE's to support using boost
> > *    Install and register an MSDN Library of the boost documentation
> 
> Did you miss my list or did you dislike everything on it?
> http://article.gmane.org/gmane.comp.lib.boost.devel/124787

No I didn't miss it, I receive the list in Digest mode which makes it hard
to find stuff sometimes (especially with this thread 150 replies).  That
list I created was from memory I am happy to incorporate your suggestions.

[SNIP ...]

> 
> > 1.    Can we write a program that could work out if a library is header
> > only? (generating a list of all these files)
> 
> What do you mean by "work out?"  Oh, I think you mean "decide."  At
> first I thought you meant "function properly."
> 
> Yes, we can.

What I am driving at is could we create a script/tool that would generate a
list detailing these files and write it to a file that can be easily
re-interpreted (ie output in XML or structured text).

Maybe something like: 

[Library Name] [File Name]
Foo Library    foo.hpp

During the build process this file will be read and incorporated into an XML
document that the Candle (WIX Compiler) and then Light (WIX Linker) will
generate the MSI from.

> 
> > 2.    Can we write a program that could work out if a library needs to
be
> > compiled as a lib file? (generating a list of all these files)
> 
> Isn't that just the inverse of question 1?

I guess so =p.  Thinking about it the same tool described above could
include this information.  So modifying the Columns:

[Library Name] [Header Only] [File Name]
Foo Library     YES           bar.hpp

The output will obviously be more complicated then this (to build the
library you need the Jam file and anything else you usually would need).

> 
> > 3.    Can we write a program that could work out the dependencies
between
> > different libraries? (generating a list of all the dependencies)
> 
> bcp

I have not used bcp so excuse my ignorance if it already can do this.  Can
you configure it to run across the whole boost source tree and spit out an
easily re-interpreted file listing the dependencies between all libraries?

> 
> > 4.    Is there a number of files that you would consider to be core
boost
> > files (ie something that the majority of boost libraries/users would
use)?
> 
> Yes, but why does that matter?  If we allow people to limit how much
> they install, they'll be offended if they get something they don't
> need, even when it's in the "core."

I guess I need to elaborate here.  This isn't necessarily for the end users
this is to hopefully simplify the dependency graph.  Ie I am guessing a
majority of libraries would use smart_ptr?  Are there other libraries like
this?

To give you an indication on how I think an end user would use the installer
(bare in mind this is pie in the sky stuff till I find out if it is possible
=p)

1. Download MSI package from boost website, which will include
        - Bjam (pre-built) (zipped currently 83k)
        - Boost Sources (zipped currently 19MB)

2. Run the MSI and follow the bouncing ball (note this is not set in stone,
just an idea of how I would love to see it)
        - View the boost License file(?)

        - Check for various Toolsets

        - Choose parts of boost to install, broken down by:
                (Note: Would need dependency information to break it down to
this level)
                * Header Only libraries
                        + Header A	
                        + Header B
                        + Header C
                        + Header D
                * Compiled libraries
                        + Lib A	
                        + Lib B
                        + Lib C
                        + Lib D
                * Documentation
                        + All (Default)
                        + Selected header/lib's documentation
                * Rest of the support files needed for boost development

                (At a minimum I would default the installation to Headers,
All documentation.  But this is open to discussion and would be easy to chop
and change)

        - Choose boost installation location
        
        - Choose the toolset

        - (Display if compiling lib's) Configure any additional options Bjam
would use

        - Display a summary of the tasks about to be preformed

3. Once they click on finish the installer will
        - Extract the Header files and documentation to install directory
        - Invoke the command line and run the Bjam command to create the lib
files
        - Update the toolset to use the boost files

As long as everything works out the process to create a new MSI file for a
new boost version for windows would be:

0. Get the stable boost branch from CVS

1. Generate header/lib XML file
2. Generate dependencies list
3. Process these files into the WIX XML document
4. Compile the WIX XML document
5. Link the WIX object files

6. Upload MSI Package to sourceforge

This could be down by Script, Bjam, Make or by hand.

Peter.