RE: [boost] Re: Customer Friendlier Boost Installation

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-05-27 04:20:44

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:

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.

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. 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

[2] the compile and link actions may be done out-of-order, so you would need 
to keep the targets/options in memory while they are being processed;

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

[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.

Summing up: it isn't easy being green ;)

> > which would generate the project files for the specified project.
> >
> > Alternatively, there could be plugins written to hook into the various 
>IDEs
> > that will import a bjam project in a friendly GUI way. (This might call 
>the
> > command-line utility so people who prefer command-line or GUI can take 
>their
> > pick.)
>
>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.

> > Perhapse what is also needed is a friendly GUI that allows you to
> > configure bjam/BBv2 and create new projects. This infrastructure
> > could hook into your favorite IDE (Eclipse, VS, BCB) so you could
> > edit build and run the jam files from inside the IDE without
> > touching the command line. This would go a long way to increasing
> > the appeal of Boost to a RAD/GUI developer. It should also be
> > possible to edit the project (jam) files directly and have control
> > over their formatting.
>
>You will also need that capability because your GUI won't be
>able to capture all the possible variability in Jamfiles otherwise.

A GUI application (either a standalone "build-me" app like John Torjo's 
Win32GUI app) or an IDE plug-in would end up calling Boost.Build/bjam. That 
was always a given.

> > 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.

Reece Haston Dunn
Software Engineer, Sophos

Web: www.sophos.com
Sophos - protecting businesses against viruses and spam