Handling New IDLs with widl

[Roy]

Howdy,

I'm looking for advice on how to integrate a new idl into wine.

I'm implementing bits and using the widl compiler on the IDL I wrote.  My
current setup places the IDL in include/ with the build system generating a
header file that it posits there.  So far, so good.

I now need to generate bits_i.c and link that into my dll located in dlls/bits.
Adding:

----
IDL_I_SRCS = $(TOPSRCDIR)/include/bits.idl
----

to dlls/bits/Makefile.in solves this problem but drops the bits_i.c into
include/.  This is rather messy.  Any advice on if I should (1) moving my IDL
into dlls/bits/ and do everything locally or (2) dig into Make.rules.in and
update the rule for *_i.c generation to allow the generated file to exist
locally with the .idl sitting in include.  The second idea is a little tricky
since the current rule is careful to rename the generated .i file with the -U
option:

----
.idl_i.c:
    $(WIDL) $(IDLFLAGS) -u -U $@ $<
----

which is a great idea, but uses the full path to the original idl when renaming
the file.  Probably good for the general case, but not for me.

Thanks for the advice!
-Roy

[Robert Shearman]

Roy wrote:
> I'm looking for advice on how to integrate a new idl into wine.
>
> I'm implementing bits and using the widl compiler on the IDL I wrote.  My
> current setup places the IDL in include/ with the build system generating a
> header file that it posits there.  So far, so good.
>
> I now need to generate bits_i.c and link that into my dll located in dlls/bits.
> Adding:
> IDL_I_SRCS = $(TOPSRCDIR)/include/bits.idl
>
> to dlls/bits/Makefile.in solves this problem but drops the bits_i.c into
> include/.  This is rather messy.

Hi Roy,

The way it's done for shared IDL files, like include/wine/irot.idl is to 
create a dummy IDL file in the directory you want to create the 
generated files in (see dlls/ole32/irot.idl) that simply includes the 
shared IDL file.

Also, you might want to use your full name when submitting patches.