From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-03 16:55:51
Alexey Pakhunov wrote:
> Hi All,
> > I volunteer for writing HOWTO describing how to convert existing
> Visual Studio project to a .jam file.
> Finally, I've finished this document. Currently it is an .rtf file with
> three example projects. I put it to Boost Sandbox Files for now:
Well, the document is about "Which files I need to build an ATL
COM-server with bb, and how to apply tlb rule". It isn't about generic
conversion issues and tricks.
I'm going to migrate to Boost from MSVC 7.1 project system, and in
complete migration guide I'd like to see there how to map the following
MSVC entities to Jam code:
* project configurations and solution configurations
* output and intermediate folders
* precompiled headers
* project macros like $(SolutionDir) including system environment pickup
* build events and custom build steps
* per-file, per-project and global paths to headers and libraries
* custom build tool
* per-file build options (including option inheritance issues in msvc
The list isn't complete, it's just first things I thought about. I think
that for large, complex projects migration can be rather hard, and a lot
of issues will appear. I'm going to create this guide as a part of
Getting Started guide I'm working on.
I think that such MSVC Migration Guide will be helpful both for
beginners trying to see how well their MSVC tasks will be performed by
Boost.Build, and for project managers trying to evaluate advantages and
disadvantages of migrating to bb. Also it will help in creation of
automated vcproj->jam conversion tools and Boost.Build plugin for MS IDE.
For now, I see only one reason for the plugin - MS Source Control API.
With makefile approach of building/debugging bb projects from Studio I
need to add all source files to Studio project manually to enable
automatic checkouts when I try to modify a file. When inconsistency
between project file set and project source tree occurs, I get hanging
checkouts, invisible from IDE, and sometimes hijacked files (files
modified without being checked out first).
Ok, let's get back to the documentation and sample projects Alexey attached.
project-root.jam is incorrect. I think toolset should be specified
externally on command line or default toolset should be configured in
With my configuration I got:
error: at project-root.jam:6
error: msvc initialization: parameter 'version' inconsistent
error: an explicit value was specified in an earlier initialization
error: no value is specified now
I think empty project-root file would be much better. For me it looks
like Alexey didn't find how to specify toolset in bb2 too, and
hard-coded msvc toolset into project file just like I used to do before
David Abrahams answered my recent question.
> But it would be better to publish it as a WIKI page or include in BBv2
> documentation. Any ideas?
You don't need to ask a permission to contribute to Wiki. The idea of
Wiki is that everyone is free to modify it, isn't it?
> I also attached the final version of .idl support for the msvc package.
> As usual, idl.jam should be placed together with the modified msvc.jam.
> After all I've decided to implement only very basic logic giving a
> developer maximum level of flexibility.
Sample projects require idl.jam and modified msvc.jam. I think you
should include them into the zip uploaded to the sandbox, or mention
these dependencies in the document.
I dislike toolset name. "IDL" looks too generic and ambigous. Microsoft
IDL isn't the only interface definition language in the world. There are
also at least OMG CORBA IDL and Mozilla XPCOM IDL, so I'd like to rename
the toolset to midl.jam and the rule to mscomtlb or something like this.
Also, consider other existing ways to write MS COM servers. For example,
Lambdasoft Comet ATL replacement from http://lambdasoft.dk/.
Do you think your solution will be able to co-exist with .idl files in
other languages and with another ways to build .tlb files (like witg
idl2h helper from Comet)? On the one hand, I'd like to see IDL separated
from C++ toolset. On the other hand, midl compiler is a part of MSVC
package... Also, consider scenario when it's desired to use newer midl
compiler from Visual Studion in Borland C++ projects instead of version
shipped with bcb.
Also I'd like to see complete patched msvc.jam, not just diff. I was
unable to try the samples because I don't have CVS installed and don't
have a tool to patch my msvc.jam. My msvc.jam differs from the version
Alexey used to create the patch.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk