Re: [Boost-build] XPIDL Tool

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-08-04 15:09:32

On 8/4/06, Klaus Nowikow <e8827661_at_[hidden]> wrote:
>
> Vladimir Prus wrote:
> > On 8/3/06, *Klaus Nowikow* <e8827661_at_[hidden]
> > <mailto:e8827661_at_[hidden]>> 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