[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost-build
Subject:    Re: [Boost-build] IDL and Qt Generator Conflict
From:       Vladimir Prus <ghost () cs ! msu ! su>
Date:       2008-11-22 9:43:09
Message-ID: 200811221243.09705.ghost () cs ! msu ! su
[Download RAW message or body]

On Friday 14 November 2008 17:52:27 Brad Howes wrote:
> All,
> 
> I'm working on a project that is attempting to use OpenDDS (from the  
> ACE/TAO team) along with Nokia's Qt. The build system works great so  
> far with just Qt. I created my own simplistic idl.jam tool that  
> invokes the two OpenDDS tools to generate the C++ files from an IDL  
> spec. For a file Foobar.idl, the first tool generates the following:
> 
>      FoobarTypeSupport.idl
>      FoobarTypeSupportImpl.cpp
>      FoobarTypeSupportImpl.h
> 
> One then runs another tool from ACE/TAO to generate C++ files from the  
> (now two) IDL files:
> 
>      FoobarTypeSupportC.cpp
>      FoobarTypeSupportC.h
>      FoobarTypeSupportC.inl
>      FoobarTypeSupportS.cpp
>      FoobarTypeSupportS.h
>      FoobarTypeSupportS.inl
> 
>      FoobarC.cpp
>      FoobarC.h
>      FoobarC.inl
>      FoobarS.cpp
>      FoobarS.h
>      FoobarS.inl
> 
> All of this works just great in Boost Build. The derived files are  
> created in the appropriate build variant directory. Here is my  
> generator line in the idl.jam file:
> 
>      type.register INL : inl : H ;
>      generators.register-standard idl.OpenDDS-IDL : IDL :  
> CPP(%TypeSupportImpl) CPP(%TypeSupportC) CPP(%TypeSupportS)
>           CPP(%C) CPP(%S) INL(%TypeSupportC) INL(%TypeSupportS)  
> INL(%C) INL(%S) ;
> 
> What I would like is to add the *.h files as well, using  
> H(%TypeSupportImpl), H(%TypeSupportC), etc. But when I do, I get a  
> Boost Build error complaining:
> 
>      Error: ambiguity found when searching for best transformation
>      Trying to produce type 'CPP' from:
>       -  { Messenger.idl.IDL }
>      Generators that succeeded:
>       -  qt4.moc
>       -  idl.OpenDDS-IDL
>      First generator produced:
>       -  { qt4%qt4.moc-moc_MessengerC.cpp.CPP { idl%idl.OpenDDS-IDL- 
> MessengerC.h.H { Messenger.idl.IDL } } }
>      Second generator produced:
>       -  { idl%idl.OpenDDS-IDL-MessengerTypeSupportC.cpp.CPP  
> { Messenger.idl.IDL } }
>      .
>      .
>      .
> 
> I certainly understand the ambiguity, though why does it happen when I  
> add "H(%C)" to the generator? Any ideas on how to coexist with another  
> generator that handles similar suffixes? For the record, my Qt stuff  
> does not use any IDL, so I could conceivably customize my qt4.jam file  
> and remove that part.

Hi Brad,
sorry for slow reply -- I've experienced cache miss while trying to answer
this, and might even have to write some code ;-)

The reason this does not happen until you add H(%C) to generator outputs
is that the first transformation:

      -  { qt4%qt4.moc-moc_MessengerC.cpp.CPP { idl%idl.OpenDDS-IDL- 
	 MessengerC.h.H { Messenger.idl.IDL } } }

makes use of the H target. If IDL generator does not produce H target, then
moc generator does not have anything to use.

I do no think this ambiguity can be automatically resolved, in general, so
some explicit override is necessary. I think the best way would be to say:

	- prevent moc generator to use H targets produced by IDL generator

I should be fairly quick to implement, but before I try, anybody sees a better
way?

This mechanism will only allow to resolve the ambiguity -- presently, we don't
have a mechanism to make Boost.Build use *both* transformations. So, if IDL
generator will ever start emitting headers that use Q_OBJECT, we'll in trouble.
But we'll cross the bridge later.

- Volodya



> 
> Finally, just a quick note of thanks to all who work on Boost Build. I  
> cannot imagine working on another project without it.
> 
> Thanks,
> 
> Brad
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
[prev in list] [next in list] [prev in thread] [next in thread]