Shared IDL Imports

[Robert Shearman]

Hi all,

I've got a patch pending in my tree that adds another IDL file in 
include/wine/ but it has a dependency on another new IDL file in the 
same directory. The trouble is that the patch in the import statement 
gets lost in the generated IDL file. The attached diff shows an example 
of this, which gives the following error:

~/Documents/wine/dlls/ole32 rob$ make
../../tools/widl/widl -I. -I. -I../../include -I../../include  
-D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H  -h -H irot.h irot.idl
gcc -c -I. -I. -I../../include -I../../include  -D__WINESRC__ -D_OLE32_ 
-DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing 
-Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith  -g -O2  
-o moniker.o moniker.c
In file included from moniker.c:48:
irot.h:11:18: error: test.h: No such file or directory

I see an number of options for fixing this, but they all have problems:

Solution 1: Fix the generation of include statements in header files 
generated from the IDL to include the path. This has the issue that it 
is not compatible with MIDL, so testing our IDL files with it becomes 
difficult (MIDL appears to only search in the current directory when it 
encounters an import statement with a path).
Solution 2: Include the dependent IDL file instead of importing it. This 
has the issue that the include needs to be guarded so that the 
definitions don't get declared if the dependent IDL file's header is 
imported before or after the first IDL file's header. This also has the 
trouble that it isn't compatible with MIDL as the guards are different 
between MIDL and widl.
Solution 3: Put the IDL files in another directory (e.g. include/idl) 
and add that to the -I statement in CFLAGS and not using a path in the 
import statment in the first IDL file. This has the issue of having to 
change the name of the IDL file in the DLL or program directory to avoid 
an infinite recursion of includes.

Which of these is the best solution or is there another solution?

Thanks,

[Alexandre Julliard]

Robert Shearman  writes:
> Solution 1: Fix the generation of include statements in header files
> generated from the IDL to include the path. This has the issue that it
> is not compatible with MIDL, so testing our IDL files with it becomes
> difficult (MIDL appears to only search in the current directory when
> it encounters an import statement with a path).

I think preserving the path is the right thing to do in any case, but
whether we want to take advantage of this feature is another question.

Does the dependency really need to be expressed in the global idl file?
Can't you simply require users of that file to import the required
dependencies first?