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...
On November 29, 2002 01:03 pm, Patrik Stridvall wrote:
With your suggestion above we can, so I like it. :-)
Yay!!!
I guess the problem is that we the current setup we can not include wine specific headers without having *our* win32 headers in the include path. Bad.
Cool thing (me thinks) about my proposal is that it doesn't complicate Winelib use at all. Right now apps need to have a -I$(prefix)/include/wine now that will change to -I$(prefix)/include/win32
The only thing I don't like in my proposal is the win32 name, namely the 32. I guess Win64 will go in the same namespace, as well as win16. This is confusing. What about winxx or even better winapi?
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...
We don't have to move anything in the tree, just modify where we install stuff. Of course, this means that you will not be able to use your tree include files in all cases, but I think it's good as a start.
-
Dimitrie O. Paun -
Patrik Stridvall