[boost] Re: Customer Friendlier Boost Installation

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-27 05:49:51

"Reece Dunn" <msclrhd_at_[hidden]> writes:

> David Abrahams wrote:
>>"Reece Dunn" <msclrhd_at_[hidden]> writes:
>> > What would be better is a way to auto-generate IDE projects from the jam
>> > files. That way you don't need to specify VC6, VC7, VC71, VC8,
>> BCB5, BCB6,
>> > CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files
>> for all
>> > the examples, libraries, etc.
>>
>>It's always been my intention that we do something like that, but of
>>course... we need someone to do it!  Care to volunteer?  The C++ world
>>will thank you!
>
> I'll take a look at it. I am not promising anything though.
>
>> > Ideally, there should be a single program that could process jam
>> > files (an extension of bjam?) that can accept a template file that
>> > tells it how the project file(s) should be structured.
>>
>>Yeah, it would have to be part of Boost.Build.  I don't even think of
>>it as an extension.  Terminology nit: Talking about making it an
>>extension of bjam is a bit weird.  bjam is an interpreter with a few
>>built-in primitives for making build systems.  Boost.Build (along with
>>your Jamfiles) is a program, essentially, that implements a build system.
>
> What I meant was that it would have to sit on top of the bjam/Boost.Build 
> architecture. The Boost.Build (v1 and v2) model does not allow for the 
> collection of information needed to generate the appropriate project
> file:

Certainly it does.  Especially v2.

> Taking VC7-8 as an example, there are "solutions" (a text file) that 
> contains the list of projects in it and any dependencies. Each project is 
> associated with a GUID (a unique hexadecimal string created via a 
> Windows/COM API call) - therefore there needs to be GUID generation (and 
> formatting) support in bjam.

No, we can just build a GUID generation tool and invoke it as part of
the process of building the project files.

> Each project is an XML file consisting of configuration information and the 
> files (grouped by category - e.g. header, source and resource files) 
> associated with the project. Each source file is built and then linked into 
> the final project. Configurations (usually Debug and Release) describe the 
> setup for building the various files, i.e. what arguments (include path, 
> defines, etc.) to the command line tools (compiler, resource compiler, 
> linker).
>
> The problems with using Boost.Build are that:
>
> [1] one configuration (variant) is processed, so your would end up with 
> release versions of the project files. 

No, an arbitrary number of variants are processed.

> Granted, these could be collated after the generation, but this
> would become:
>
>   bjam project=myproject release msvc-7.1
>   bjam project=myproject debug msvc-7.1
>   collate-project msvc-7.1

I guess not.

> [2] the compile and link actions may be done out-of-order, 

What do you mean by "out-of-order?"  A link action is never done
before a compile action that it depends on.

> so you would need to keep the targets/options in memory while they
> are being processed;

targets and options already are kept in memory while they're being
processed.

> [3] settings (include paths, etc.) need to be extracted from the compiler 
> and linker and then placed in the global configuration settings;

?? Please explain.  What do you mean by "extracted from the compiler
and linker?"  Surely you don't have to specify in the project file any
options that are built into the command-line tools and don't need to
be specified from the command line?

> [4] you need to generate a top-level solution file ('myproject') and one 
> project per exe/lib target, possibly specifying post-build actions for 
> install/stage commands.

I don't see the problem here.

>>Unless it is actually executing bjam to build the project, it is
>>unlikely to work right.  There's too much possible variability in
>>Jamfiles, since they are essentially program fragments.
>
> The way I indended was to do something like:
>
>   bjam -n release ... > release.log
>   bjam -n debug ... > debug.log
>   bjam -n profile ... > profile.log # optional?
>
> filtering/processing the results so that the .log files would contain the 
> project meta-data in a form that could be easily processed and collated by 
> the project generation tool based on the project template provided.

Don't do it.  Regression testing is already extremely fragile because
we're using that approach.  We've been intending to generate the XML
directly using Boost.Build, but haven't gotten to it yet.

>> > Summing up, there would be a GUI-based:
>> > *  setup/configuration of Boost;
>> > *  project creation wizards to create BBv2 projects;
>> > *  conversion tool to convert to your favorite IDE format;
>> > *  hook-ins to allow BBv2 projects to be managed in your favorite IDE.
>>
>>Not bad.  Care to take up the challenge?
>
> Sure, why not :)
>
> I have a bjam log to xml converter with a really neat XSLT that can
> take care of various compilers output formats (microsoft, borland,
> gcc and metroworks at the moment). I am getting it ready to add to
> the sandbox vault.

If we get further tied into the log processing approach I think it
will be a shame.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com