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.
Patrik Stridvall ps@leissner.se writes:
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.
Well, it's somewhat better, but it's still too complex IMO. Maybe what we should do is put the (3) headers directly in /usr/include, like /usr/include/wine_unicode.h. But this would work only if we don't have many of them, so we probably want to work on simplifying this first.
Also note that this is not going to solve your problem, because wine/test.h is more a category (2) header (or maybe you need a new category for Wine internal headers that don't get installed).
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.
Not an option. If we have to move the files we'll move them; it's better to avoid moving things around too much. but we shouldn't let CVS limitations impose a broken structure. Now if we can find a non broken structure that also doesn't involve moving files that's better.
-
Alexandre Julliard -
Patrik Stridvall