Patrik Stridvall ps@leissner.se writes:
I would like to have a directory structure like
include: Wine's version of Windows headers include/wine: Wine's internal headers include/wine/wine: Wine's "extension" headers
With "extension" headers I mean that headers that are exported and usuable by Winelib applications.
That's ugly IMO.
The specific solution above, perhaps.
However I think it would be very useful to make a proper distinction between
1. The Wine version of Microsoft headers 2. Anything that Wine uses to communicate internal 3. Extensions that Winelib applications can use.
Perhaps (2) and (3) are not much different (se below), but (1) and (2/3) are clearly different.
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.
Besides there is no such distinction between internal and "extension" headers, all the headers in include/wine are supposed to be usable by Winelib app.
Sure there are. Not all header from include/wine are copied to /usr/local/include/wine/wine during. The ones that are not copied are "internal" and the ones there are are "extensions" in some meaning.
Only the "exension" headers (ie header that are copied during install) can be used by Winelib applications.
However that might perhaps only be a temporary distiction.
Anyway
cd include/wine mkdir wine mv *.h wine
work for me as well if you prefer that.
I'd suggest you simply copy the ones you need with MSVC somewhere else to avoid conflicts.
Hmm. Yes, that is another possibillity (read: kludge).
Don't really like copying source files around, but it would work (with the possible exception of dependecies, but then "Rebuild all" is your friend :-).
In short: I still think that we should require another -I to access the Wine specific (internal and extension) headers.
However I don't really care if we do
(1) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/include/wine (2) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/$(WHATEVER)
I just don't think just doing -I$(TOPSRCDIR)/include like now is good for the reasons given above and below.
Sometime you only want the Wine specific header sometimes you only want Wine's version of the Windows header. "Forcing" everybody to take them as a package only gives rise to unnessary problem like the one I'm trying to solve.
Sure I could kludge it, but why not try to solve it properly?
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.
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). 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.
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.
I would really also like I easy way to be able to use/see where the Mingw/W32api package is hosed rather then using the WINE headers. ATM if I want to work on porting a DLL then we have to fork the hell out of it to see where the headers a hosed.
Thanks Steven
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/