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

[Patrik Stridvall]

> Patrik Stridvall <ps at leissner.se> writes:
> 
> > 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?
> 
> A clean solution? Seriously this is ugly as hell;

It would have been nice if had been cleaner yes, but then
you can't have everything can you? :-)

Seriously, I think we can do a little better. See below.

> especially when you
> consider that after you install you will get Wine headers in
> /usr/include/wine, /usr/include/wine/wine and
> /usr/include/wine/wine/wine. 

Correct. [I think we understand each other at least this time]

> Tell me this isn't confusing...

First of all you have /usr/include/wine and /usr/include/wine/wine
even today. Which already is a little confusing. But hey it works
for most thing so I'm not complaining that much.

But yes, it is a little confusing.
Hmm. Thinking....

We could do that following instead:
(1) /usr/include/wine => /usr/include/wine/windows
(2) /usr/include/wine/wine => /usr/include/wine/windows/wine
(3) /usr/include/wine/wine/wine => /usr/include/wine

Also note (2) will disappear eventually.

This would be very nice since now normal Winelib applications 
ie ports from Windows can do -I/usr/include/wine/windows
regardless of whether they use the Wine "extensions" or not
since #include "wine/test.h" for example will work without a -I.

"Special" Winelib application could do
#include "wine/windows/wincrypt.h"
without any -I if somebody for example 
wanted to use the Windows encryption API 
in a normal Unix application.

Hmm. Perhaps /usr/include/wine/windows should be /usr/include/wine/win32
instead, with perhaps /usr/include/wine/windows as symbolic link to
/usr/include/wine/win32. But that is just details, what do you think
in principle.
 
> If you really want to make it possible to mix and match headers from
> different sources, you need a more serious redesign of the whole
> include layout, and you need to ensure that the normal case is at
> least as easy and clean as it is today.

I think the suggestion above would do nicely.

Internally in the wine tree I think we might have to choose the 
ugly include/wine/wine solution, but we could install to the
solution above which is what's really important.

PS. Of course we could move include/*.h to include/wine/windows or
something like that but then it is no real use and beside it ruins
the cvs patch log. Better stick to the ugly include/wine/wine
solution interally IMHO.