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,
> > CodeWarrior, Eclipse, insert-your-favorite-IDE-here project files for
> > 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,
The problems with using Boost.Build are that:
 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
 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;
 settings (include paths, etc.) need to be extracted from the compiler
and linker and then placed in the global configuration settings;
 you need to generate a top-level solution file ('myproject') and one
project per exe/lib target, possibly specifying post-build actions for
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
> > that will import a bjam project in a friendly GUI way. (This might call
> > command-line utility so people who prefer command-line or GUI can take
> > 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
Reece Haston Dunn
Software Engineer, Sophos
Sophos - protecting businesses against viruses and spam
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk