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.
Patrik Stridvall ps@leissner.se writes:
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?
The complexity is that you create up to 3 levels of directories under /usr/include, I don't think such a deep hierarchy is really necessary.
I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h
Well, the difference is that you can then use /usr/include/wine for the Windows includes.
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.
I agree getting the Wine tests to work soon is important, but you don't really need the final header organization for that; you can easily work around the current problem by copying files around or specifying an absolute -I option.
I don't think we have found a fully satisfying solution yet, and IMO the situation will be clearer when the dll separation is finished and the loose ends are cleaned up, so I'd prefer to wait until then to decide on the final structure. (And my secret hope is that by then we will be able to switch to Subversion which should make renaming files a lot easier; but that's another topic...)
On October 22, 2002 07:12 pm, Alexandre Julliard wrote:
decide on the final structure. (And my secret hope is that by then we will be able to switch to Subversion which should make renaming files a lot easier; but that's another topic...)
Oh my, you think it's going to take us _that_ long?!? :P
-
Alexandre Julliard -
Dimitrie O. Paun -
Patrik Stridvall