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.
Where is the complexity?
If you want to port a Window application, you add -I/usr/include/wine/windows and everything as much as like under Windows as possible. If you in addition wish to call some Wine "extension" no problem just do #include "wine/foo.h" or similar.
If you just want to use the Windows API in an Unix application you need anything at all. Just do #include "wine/windows/wincrypt.h" and you're done.
[Linking is a separate problem, of course. But then, this changes nothing as far as this is concerned]
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.
I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h
None of them requires any -I. It is more a convention that if you have many .h you have a directory, if not, well then you can have a directory anyway, it is up to you.
Also note that this is not going to solve your problem, because wine/test.h is more a category (2) header
Well wine/test.h is really kind of a special case anyway it could be moved to programs/winetest/include/wine or something under whatever name it is not really a concern.
Perhaps we should move programs/winetest/wtmain.c to test/ and make it a library similar to library/ and unicode/. This is what I did with MSVC, eventhough I did it in programs/winetest instead.
(or maybe you need a new category for Wine internal headers that don't get installed).
You mean for files like windef16.h?
Well, in the long run such files really belongs in the dlls/* directories. In the extent that that can't they really are Wine "extension" that might as well be used by any Winelib application not just internally should IMHO be installed.
But yes, we certainly need some place to put them in the meantime, since this isn't happing over night. However I think that they can remain in include/wine/ until we move them one by one. See below.
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.
OK.
Now if we can find a non broken structure that also doesn't involve moving files that's better.
Perhaps this would work:
mkdir library/wine mv include/wine/{library,port}.h library/wine
mkdir unicode/wine mv include/wine/unicode.h unicode/wine
mkdir dlls/ntdll/wine mv include/wine/exception.h dlls/ntdll/wine
Sure it would mean a few more -I internally but it would not be that bad.
Then during install all these files as well as some files from include/wine/ ends up in /usr/include/wine and the include/ files end up in /usr/include/wine/windows or /usr/include/wine/win32 not sure what is best.
That would require moving a minimum of files. As before eventually far in the future include/wine/ would be empty. Transition done.
We needn't move everything right now either. As mentioned before running the Wine test with the Microsoft headers currently AFAICS only requires that we fix wine/{exception,test,unicode}.h.
Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though.