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