d3d8 CVS doesn't compile
lionel.ulmer at free.fr
Wed Apr 28 13:21:45 CDT 2004
> That seems really overkill. It's OK to define some symbols ourselves
> when they have well-known values, but I don't think shipping the full
> headers is really necessary; and I don't see how it would solve issues
> like the above anyway.
Well, the more 'recent' extensions we will use, the more problems we will
have. So, to fix all these 'Wine CVS does not build' issues, we can either :
1) test ALL extensions we plan to use in the configure script and disable
on an one-per-one basis. Which is a pain to maintain and not really
in-line with what OpenGL provides (as extension should be checked at
run-time and not at compile time to have one binary work everywhere).
2) do some 'partial' re-implementation of OpenGL headers in the Wine source
tree (which is what is done in the dlls/d3d8/d3dcore_gl.h file)
3) ship ourselves the most up-to-date version of the OpenGL headers
(actually, we could only ship glext.h but due to bugs in some vendors'
gl.h and glx.h files, it's a bit problematic) which would mean removal
of all the #ifdef / #endif in the code and all the re-definition of the
constants in the d3dcore_gl.h file.
What I prefer in the third solution is its 'simplicity'... I.e. maybe
shipping glext.h ourselves is overkill, but at least we will develop against
a known target instead of having to each time copy / paste the needed
extensions in our own header files one by one.
Anyway, it's more Raphael's problem than mine so I will let him continue the
discussion if he wishes to :-)
Lionel Ulmer - http://www.bbrox.org/
More information about the wine-devel