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

[Patrik Stridvall]

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

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

[Alexandre Julliard]

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