Patrik Stridvall ps@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.