On 8/4/06, Klaus Nowikow <e8827661@student.tuwien.ac.at> wrote:
Vladimir Prus wrote:
> On 8/3/06, *Klaus Nowikow* < e8827661@student.tuwien.ac.at
> <mailto:e8827661@student.tuwien.ac.at>> wrote:
>
> > Some time ago, I started a thread about an XPIDL tool, see
> > http://article.gmane.org/gmane.comp.lib.boost.build/13076
>
> Hi Klaus,
> it would be great if you add this patch to our tracker (see link at
> boost.org/boost-build2 <http://boost.org/boost-build2>), so that it does
> not get lost and I look at it in detail when I'm back from vacation

Done -- Ticket #99
 
 
Thanks.
 

> [...]
> > There is only one problem: when used with the MSVC toolset it
> > clashes with midl.jam, because msvc.jam imports midl.jam.
> > Both midl and xpidl register a new type IDL, and both add a
> > generator to create other files from an *.idl file. I can't
> > think of any solution to that besides not importing midl.jam
> > from msvc.jam. Any ideas?
>
> Add a new file in tools/types directory, and remove declaration of IDL
> type from your module and midl.jam.

That's a start, but it solves only the first half of the problem.
There are siill two generators that generate IDL -> OBJ, see the output
of 'bjam -n' below. I used my own project to test it, which is too large
to show here, but I can provide a minimal test case if you need one.

I have to mention here that the xpidl generator produces a dummy C
file which is never used -- I just 'touch $(<[4]:W)' to produce it.
 
I recall we have such problem, I think that qt4.jam has some solution for a related problem, but I forgot lots of things in last few days ;-)
 

This is to make sure that the generated files go into the dependencies
-- a little clumsy, but I couldn't figure out another way to achieve
that. The generator in my original post generated a dummy CPP file,
but I changed that so that the error messages are clearer.

# bjam -n output:
Error: ambiguity found when searching for best transformation
Trying to produce type 'C' from:
-  { IRenderWidget.idl.IDL }
Generators that succeeded:
-  msvc.compile.idl
-  xpidl.compile.idl
First generator produced:
-  { msvc%msvc.compile.idl-IRenderWidget.tlb.MSTYPELIB { IRenderWidget.idl.IDL } }
-  { msvc%msvc.compile.idl-IRenderWidget.h.H { IRenderWidget.idl.IDL } }
-  { msvc%msvc.compile.idl-IRenderWidget_i.c.C { IRenderWidget.idl.IDL } }
-  { msvc%msvc.compile.idl-IRenderWidget_proxy.c.C { IRenderWidget.idl.IDL } }
-  { msvc%msvc.compile.idl-IRenderWidget_dlldata.c.C { IRenderWidget.idl.IDL } }
Second generator produced:
-  { xpidl%xpidl.compile.idl-IRenderWidget.xpt.XPTYPELIB { IRenderWidget.idl.IDL } }
-  { xpidl%xpidl.compile.idl-IRenderWidget.h.H { IRenderWidget.idl.IDL } }
-  { xpidl%xpidl.compile.idl-IRenderWidget.java.JAVA { IRenderWidget.idl.IDL } }
-  { xpidl%xpidl.compile.idl-IRenderWidget.c.C { IRenderWidget.idl.IDL } }
 
 
Recall me, what is the real type that you need to produce from IDL. In any case, if you have some "IDL file" in source of a main target, V2 has to decide which generator to use. There are two approaches:
 
    -  Add new <idl_toolset> property. I think we've discussed this with Reece and Andrey, but did not agree if that's a good
       idea or not. IIRC, one concern was that it does not scale as we add more and more tools. But this approach can still
       work in you case.
 
   - Use different type for sources to MSIDL and XPIDL. You can either use different extension (which is ugly), or
     use the 'cast' rule to explicitly say which type a given source has.
 
 
- Volodya