Re: [bbv2] Support of .idl files

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

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

[skipped]

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

[skipped]

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 
thoughts:

IDL scanner:

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

MIDL:

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.

Best regards,
Alexey Pakhunov.