[RFC] Adding an include/wine/wine directory?

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > Perhaps (2) and (3) are not much different (se below),
> > but (1) and (2/3) are clearly different.
> 
> Well yes, that why they are in different directories. (1) is in
> include and (2/3) is in include/wine.

Yes, but because of how they are positioned in the filesystemet
and used by C they are effectively "packaged together" in a bad way.

It seems that I'm not the only one having this problem as well.
Steven Edwards also wants a way to use the Mingw/W32api
package together with Wine in a sane way.

But I have a plan how to smoothly migrated from the current layout
to a new layout. See below.
 
> > That is why I think "-I../../include" shouldn't automatically give
> > you (2) and (3) as it does now. Having to add -I../../include/wine
> > or whatever to get it would make it possible in addition to
> > solving my MSVC Microsoft header problem to make it possible to
> > uses the Microsoft headers or whomevers headers even on Linux.
> 
> The problem is that then you require everybody who wants to use
> Winelib to add stuff to their include path, even if they don't use any
> Wine header directly (since our Windows headers reference the Wine
> ones).

They currently do, yes. That is why I initially suggested creating
a include/wine/wine and only moving the "extension" headers like over
to include/wine/wine.

The "extension" headers are files in include/wine like debug.h, exception.h,
library.h, port.h, server.h, test.h, unicode.h that isn't or shouldn't
be included by our Windows headers. In the extent that they are it is a bug
IMHO and AFAICS one that is quite easily fixed in most cases as well.

However, in the first phase to get the all the tests running I AFAICS
only need exception.h, test.h and unicode.h. Of them only unicode.h
is currently used by the Wine headers (file.h and heap.h). However
fixing that shouldn't really be a problem. I will look into it.

I suggest that we gradually move the files in include/wine
to include/wine/wine or in some cases other places like the DLL
directories. Eventually, far in the future, the include/wine directory
will be empty (save for a wine directory).

This provides a slow and steady migration path from the old 
to the new that doesn't have any of the problems you described. 
What more can you ask for?

> So you are making the normal case more complex to simplify the
> very unusual case of mixing headers. I prefer to ask people who want
> to mix headers to do some extra steps and make the common case as easy
> as possible.

As stated above the problem can be solved. Wine itself is AFAIU 
(not tested) fixed by this patch. Nothing more should be needed.

Index: Make.rules.in
===================================================================
RCS file: /home/wine/wine/Make.rules.in,v
retrieving revision 1.131
diff -u -r1.131 Make.rules.in
--- Make.rules.in       19 Oct 2002 17:15:00 -0000      1.131
+++ Make.rules.in       22 Oct 2002 09:02:33 -0000
@@ -45,7 +45,7 @@
 LN        = @LN@
 LN_S      = @LN_S@
 TOOLSDIR  = @TOOLSDIR@
-DIVINCL   = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include
$(EXTRAINCL)
+DIVINCL   = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include
-I$(TOPSRCDIR)/include/wine $(EXTRAINCL)
 ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS)
 LD        = @LD@
 LDFLAGS   = @LDFLAGS@

Normal Winelib application have shouldn't (and needn't) use the Wine 
"extension" header so they don't need the in the include path them.
The few application that does, can be very easily fixed simply by
adding an additional -I, which isn't to much to ask IMHO.