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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-02 04:07:53

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.

> 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.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2