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

[Patrik Stridvall]

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