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?