New subject: [RFC] Adding an include/wine/wine directory?

22 Oct 2002

...
Patrik Stridvall <ps(a)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.

    

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

Patrik Stridvall

Steven Edwards

Alexandre Julliard

tags

participants (3)