David Abrahams wrote:
"Reece Dunn" <msclrhd@hotmail.com> 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