Re: [jamboost] Re: [V2] Support of .idl files (second attempt or everybody ignores me :-))

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-06-02 07:15:53

Vladimir Prus wrote:
>Hi Alexey,
> > Reece Dunn wrote:
> > > <proxy>merge
> > > you should also have
> > > <define>_MERGE_PROXY
> >
> > [skip]
> >
> > > feature proxy : no yes merge : composite ;
> > > featute.compose <proxy>merge : <define>_MERGE_PROXY ;
> > > # ...
> >
> > Yes, I tried this and it works. The only problem with it is that the
> > composite feature should be "propagated" feature. At least when I
> > defined it as "free composite" it wasn't expanded at all. So as soon as
> > it is propagated an additional build directory "proxystub_yes" is
> > generated for proxy dll. As result midl.exe is called twice - to
> > generate .c in the main project directory and in proxy dll directory.
> > Doing the same job twice is not a good idea I would say.
>
>I must admit I'm a bit lost in this thread because I'm don't know COM and
>don't know what those proxies are.
>
>You seem to raise several questions.
>
>1. What's the best way to use an IDL file.
>
>I think that if possible, just putting it to sources should work.
>
>Then, you ask:
>
> > 1. MIDL is called twice since normal/proxy dlls are placed into
> > different directories.
>
>What are normal and proxy DLLs? I suspect this problem is not solvable in
>the current Boost.Build, but we're planning to address it.

There are two DLLs that are generated in COM: the "normal" DLL provides the 
implementation of the COM object along with the entry points to create and 
manage it and the "proxy" DLL which contains the code generated by the MIDL 
compiler to allow a COM object to be used over process and computer 
boundaries using RPC (Remote Procedure Call). It is possible to have a 
"merged" DLL that contains the code for both the "normal" and "proxy" DLLs.

> > 2. Proxy dll requires several defines to be defined and a few libraries
> > (like rpcrt4.lib) to be linked with it. It would be nice if this was
> > done automatically.
>
>I think you've decided to use composite feature already? And that generates
>some file to two directories. If you tell me exactly what's generated, and
>what should be generated twice, and what once -- that is, what kind of 
>targets
>are affected by dll type, I'll take this into account when implementing V2
>support for such situations.

When compiling $(idl), the MIDL compiler generates the following files 
(which should only be generated once):
* $(idl).h -- the C/C++ interfaces to the COM objects;
* $(idl).tlb -- the type information for the COM objects that allows 
scripting languages (e.g. VB) to use the COM objects;
* $(idl)_i.c -- the GUID definitions;
* $(idl)_dlldata.c -- DLL data (not sure exactly what this contains);
* $(idl)_p.c -- the proxy stubs to allow COM object usage across process 
boundaries via RPC.

The $(idl)_dlldata.c and $(idl)_p.c files should only be compiled and linked 
if you are building a proxy/merged DLL with the defines _WIN32_WINNT=0x0500, 
USE_STUBLESS_PROXY and ENTRY_PREFIX=Prx, and the following libraries 
included: rpcns4.lib and rpcrt4.lib.

The solution I was aiming for was to generate the _dlldata.c and _p.c files 
as .gen files so Boost.Build would not compile them, then generate a .c file 
that includes these in, having setup the appropriate definitions and 
libraries. However, my solution does not quite work yet.

Reece Haston Dunn
Software Engineer, Sophos

Web: www.sophos.com
Sophos - protecting businesses against viruses and spam