> Alexandre,
>
> Patrik brought up the header location sometime ago, in this thread:
> http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540
>
> At the time, I thought it is a bit premature, that we have other
> things to do. Now I realize that this is one of those highly visible
> external things, that would be a _lot_ better to fix before people
> start using Winelib. Otherwise will piss people off when we change,
> or we will not change because people are already using the headers.
True.
> Both versions are not good, and I think we can fix them now without
> too much pain.
>
> Here is my proposal:
> ${prefix}/include/win32 -- standard Win32 headers
> ${prefix}/include/msvcrt -- MS Visual C Runtime library
> ${prefix}/include/wine -- Wine specific headers
>
> It is simple (to understand & implement), clean, and pretty.
> And I think it solved Patrik's problem (even if I can't quite
> understand what the problem is from the first message :)),
It not easy to mix different flavours of the Win32 headers
because of include problems.
The problem is that is you have since we include wine specific files like:
#include "wine/debug.h"
we need to have a include path like
-I${prefix}/include
However now since the Wine version of the standard Win32 header are in
${prefix}/include
we get them included as well if we do
-I${prefix}/include
So if we do for example
-I/opt/microsoft/windows/include
we get header include collisions.
Sure with GNU C on Linux (and presumably) on Windows we can fix that
by specifing a correct include order. However with Microsoft C++
we can't do it in a portable way.
With your suggestion above we can, so I like it. :-)
> plus a bunch of other things (like making it easy to use other
> headers for the Win32 API, etc). And best of all, it seems to
> be easily implementable, no?
"mv" is your friend however the CVS versioning doesn't like it though...
