Patrik Stridvall ps@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.