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

[Patrik Stridvall]

> Patrik Stridvall <ps at 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?