From: Alexey Pakhunov (alexeypa_at_[hidden])
Date: 2005-07-04 12:48:20
Andrey Melnikov wrote:
> 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.
Exactly. :) This message is a tail of the discussion about MIDL support
as a part of MSVC package that took place about 1 month ago. Sorry for
> 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:
I guess it would be valuable to post this note as a part of BBv2 TODO list.
> project-root.jam is incorrect. I think toolset should be specified
> externally on command line or default toolset should be configured in
Good point. I'll update it.
>>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?
Yeap. The question is rather "Do we want it as a BBv2 DocBook?".
> 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.
Well, I supposed the patch will be submitted to CVS soon.
> 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.
The problem here is that only one scanner is allowed per file type (see
the 'type.set-scanner' rule). Probably we need to implement the same
override functionality for scanners as the rule 'generator.override'
does for generators.
Renaming part is not a problem. :)
> Also, consider other existing ways to write MS COM servers. For example,
> Lambdasoft Comet ATL replacement from http://lambdasoft.dk/.
It is a matter of finding a volunteer who will write a toolset for
Comet. Basically it will contain rules and actions invoking idl2h.
idl.jam will be reused.
> 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)?
Yes, it will. I believe the limitations of the current solution will be
easily solved once one implements support of other IDL dialects. Few
- It may be common for all variants of IDL.
- It is also possible to implement some kind of scanner override
functionality like I mentioned above.
The only bad thing about MIDL.EXE support is that it is tightly coupled
with MSVC package. I guess a solution allowing to separate them will be
found if needed.
> 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 Studio in Borland C++ projects instead of
> version shipped with bcb.
I see the whole bunch of troubles here.
- What is the "standard" configuration of a "standalone" midl.exe? Will
it be a part of VS installation or just a separate .exe?
- How will one configure MIDL if it will be a separate BBv2 toolset?
- How to deal with several versions of VS installed?
> 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.
I really do not see a better way of sending a patch then sending a diff
against the latest CVS version available.
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