RE: [jamboost] Re: [V2] Support of .idl files

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-05-18 17:07:42

Alexey Pakhunov wrote:
>Reece Dunn wrote:
>
> > Can you get it so that it generates the other files as well? The proxy 
>stubs
> > (%_p.c), dlldata (%_dlldata.c) and type libraries (%.tlb).
>
>.tlb is generated already. I forgot to mention it. :)
>
>I'm going to add proxy generation as well. Basically my goal is allow
>building COM servers like wizard-generated project in Visual Studio does.

That would be very cool :)

> > Does the following work:
> >
> > lib mycomdll : myidl.idl mycomdll.cpp ;
> >
> > // mycomdll.cpp
> >
> > #include <initguid.h>
> > #include "myidl.h"
> > #include "myidl_i.c"
> >
> > // ...
>
>Currently you need not include "myidl_i.c". It will be compiled and
>linked automatically. I did nothing to achieve it. This works because of
>the way how Boost.Build build dependencies.

I have had a chance to try out your idl toolset and you are right. The 
problem would be when building the proxy stub/dlldata code as these need to 
be build from a driver file.

I have got the basics of a solution for generating the proxy stubs, but it 
still has a few problems. The idea is to not generate the _p and _dlldata 
files as C targets, but as a GEN target (generated). This means the file is 
not automatically built.

The next stage is to generate a file that includes these with the 
surrounding proxy code.

-- idl.jam --

type.register GEN : gen ;

-- msvc.jam --

import print ;

import rc ;
import idl ;

# ...

generators.register-c-compiler msvc.compile.idl : IDL : C(%_i) H TLB 
GEN(%_p) GEN(%_dlldata) C : <toolset>msvc ;

# ...

actions compile.idl
{
$(.IDL) /nologo /robust /U$(UNDEFS) /D$(DEFINES) $(MIDLFLAGS) 
/I"$(INCLUDES)" /iid "$(<[1]:W)" /h "$(<[2]:W)" /tlb "$(<[3]:W)" /proxy 
"$(<[4]:W)" /dlldata "$(<[5]:W)" "$(>:W)"
}

# ...

rule compile.idl ( targets + : sources * : properties * )
{
print.output $(targets[6]) ;
print.text [ on $(targets[1]) return "#ifdef _MERGE_PROXYSTUB // merge 
proxy stub DLL" ] ;
print.text [ on $(targets[1]) return "#define REGISTER_PROXY_DLL // 
DllRegisterServer, etc." ] ;
print.text [ on $(targets[1]) return "#define _WIN32_WINNT 0x0500 // for 
WinNT 4.0 or Win95 with DCOM" ] ;
print.text [ on $(targets[1]) return "#define USE_STUBLESS_PROXY // 
defined only with MIDL switch /Oicf" ] ;
print.text [ on $(targets[1]) return "#pragma comment(lib, 
\"rpcns4.lib\")" ] ;
print.text [ on $(targets[1]) return "#pragma comment(lib, 
\"rpcrt4.lib\")" ] ;
print.text [ on $(targets[1]) return "#define ENTRY_PREFIX	Prx" ] ;
print.text [ on $(targets[1]) return "#include \"$(<[5]:W)\"" ] ;
print.text [ on $(targets[1]) return "#include \"$(<[4]:W)\"" ] ;
print.text [ on $(targets[1]) return "#endif //_MERGE_PROXYSTUB" ] ;
}

-- [end] --

There are several problems with this at the moment:
* the generated target (C) - dlldatax.c in an ATL project - gets added to 
instead of the content being replaced with the new generated text.
* the targets in the #include statements don't get evaluated to just the 
file name (e.g. myidl_p.gen instead of ^<pbin\...^>myidl_p.gen)
* the appropriate .h file for the proxy stub (dlldatax.h) is not generated.

Maybe this will lead you in the right direction...

> > You need to ensure that the IDL file is processed first (so that the 
>source
> > files can use the generated files) and that the output path is added to 
>the
> > include path.
>
>This also works. See
>http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/bbv2/reference/jamfiles.html#bbv2.reference.headers

Now I know that BBv2 rocks ;)

> > It would also be a good idea to provide support for CORBA IDL 
>compilation,
> > although I don't know enough about CORBA to know what needs to be 
>changed.
> > What would happen if you have a CORBA IDL file and use:
> >
> > lib corbaidl : corba.idl ... ;
>
>Honestly I know nothing about CORBA and CORBA idl. In order to support
>CORBA .idl we will need (probably) to modify the scanner and use
>separate toolset for building CORBA .idl files.

That, or providing the CORBA IDL as the default behaviour in a similar way 
to how the RC tool works.

> > with msvc?
>
>Well, I don't know is it really possible but it can look like this:
>
>lib midl_lib : a.idl<toolset>msvc ;
>lib corba_lib : b.idl<toolset>corba ;

I think the syntax would be a.idl/<toolset>msvc, but yeah that should be 
enough.

Reece Haston Dunn
Software Engineer, Sophos

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