Re: [jamboost] [bbv2] Support of .idl files

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-07-04 13:36:31

Alexey Pakhunov wrote:
> Andrey Melnikov wrote:
> 
> [skipped]
> 
> I guess it would be valuable to post this note as a part of BBv2 TODO list.
> 
I'll post it into Wiki. At least it won't be totally forgot in this case.
> 
>>>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?".
> 
I'd like to see it as a DocBook in the next release. But Wiki has an 
advantage for draft docs: it is live.

>>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. :)
> 
I think that allowing just

exe hello : a.cpp a.idl ;

is a bad idea. An XPCOM component can be MSCOM client or even MSCOM 
server at the same time. So multiple different types of IDL can be in a 
single project:

exe hello : a.cpp a.idl b.idl ;

How we can solve the conflict between midl and xpidl compilers?

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

Midl.exe itself is tigtly coupled with MS Platform SDK which can be used 
as a standalone product (the latest one contains C++ compilers). The 
same MS SDK is shipped with both Microsoft and Borland compilers, and I 
think other compilers for Windows use it too.

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

Why not? Visual Studio is often used with newer Platform SDKs, and it's 
documented and supported way.

> - What is the "standard" configuration of a "standalone" midl.exe? Will 
> it be a part of VS installation or just a separate .exe?

Midl compiler is a part of MS Platform SDK. It cannot be used without 
PSDK, but PSDK itself is a standalone product.

> - How will one configure MIDL if it will be a separate BBv2 toolset?

using midl : msvc ; # midl installed with Visual Studio 2002
using midl : vc-7_0 ; # midl installed with Visual Studio 2002
using midl : vc-7_1 ;
using midl : borland ;
using midl : mspsdk ; # from standalone psdk installation

Some configurations can be inconsistent, e.g.

using msvc ;
using msvc : borland ;

But the following 2 scenarios are frequently used and are pretty legal:

using midl : msvc ;
using msvc ;

using midl : psdk ;
using msvc ;

The problem is that midl and c compiler are orthogonal things and it's 
hard to find the best way of interaction between them.

I think the problem is related to lack of ability to configure which 
platform sdk is used by VC and other toolsets:

<psdk>standalone
<psdk>builtin
<psdk-version>

So I think we should have PSDK module (don't know if it really has to be 
a toolset) with midl support built in it. PSDK module should have path 
autodetection facilities and ability to add PSDK include and lib paths 
to compiler options.

> - How to deal with several versions of VS installed?

That's a big problem. See above.

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

If I'm a developer wanting to review if patch is worth submitting, I'd 
look at patch.diff. But if I'm not an active developer, don't have quick 
access to CVS and want just to try it out, full version would be better.

I think having both .diff ad full file will satisfy both worlds.

Andrey