X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=docs%2FREADME.WIN32;h=97e1ffb7a754d7a40fbdca5a01a188193cc41c85;hb=2dcd4ce4b62122d1088d130bade83bd051fa6d0c;hp=46e38d385a1bd707a7db1d1fb3ed14a9af4307ac;hpb=10730663a128c35c0241a79d885665e6272014d7;p=mesa.git diff --git a/docs/README.WIN32 b/docs/README.WIN32 index 46e38d385a1..97e1ffb7a75 100644 --- a/docs/README.WIN32 +++ b/docs/README.WIN32 @@ -1,94 +1,163 @@ File: docs/README.WIN32 -Last updated: Aug 15, 2002 - Karl Schultz - kschultz@users.sourceforge.net +Last updated: Apr 25, 2007 - Karl Schultz - kschultz@users.sourceforge.net Quick Start +----- ----- -If you have Microsoft Visual C++ 6.0 installed, simply go to the top directory -of the Mesa distribution and type 'nmake -f Makefile.win NODEBUG=1' for -an optimized build. Note that you may have to run ...VC98/BIN/VCVARS32.BAT -to set up the appropriate compiler environment variables. - -Details and Notes - -- Building Mesa as noted above should visit and build the following: - src MesaGL.dll, MesaGL.lib, osmesa.dll, osmesa.lib - si-glu MesaGLU.dll, MesaGLU.lib - src-glut glut32.dll, glut32.lib - demos a handful of demo executables. - book more examples - samples more examples - -- After building, you can copy the above DLL files to a place in your PATH - such as $SystemRoot/SYSTEM32. If you don't like putting things in a - system directory, place them in the same directory as the executable(s). - For example, you can copy the DLL files to the demos directory if you - just want to run the demos. The build process places the DLL and LIB files - in the ./lib directory. The makefile creates this directory if it does - not already exist. - -- The make targets 'clean' and 'clobber' will remove objects and libraries. - But the files in ./lib are never cleaned. - -- The make target 'install' will take its best shot at copying DLL files, - LIB files, and headers to the right places. I strongly suggest that - you examine the makefiles to make sure that 'install' doesn't do anything - that you can't live with. - -- The makefiles are designed to work with Microsoft's NMAKE, and do, - unfortunately, have some Microsoft-specific things in them. If you - would like to use gcc or some other build tools like the Cygnus tools, - then you will have to hack the makefiles to make them work with your - tools. I'm sorry about this; I wasn't motivated to make this any - different, but if you end up modifying the makefiles for your tools, - you can send me the changes and I can apply the changes to the - source tree. - -- There are no Microsoft Visual Studio project files. However, these - should be very easy to create. One can use the compiler and linker - options found in the makefiles to make quick progress in creating - projects. - -- The DLL files are built so that the external entry points use the - stdcall calling convention. - -- Static LIB files are not built. The LIB files that are built with - the current makefiles are the linker import files associated with - the DLL files. If static LIB's are desired, it should not be too - difficult to modify the makefiles to generate them. - -- The si-glu sources are used to build the GLU libs. This was done - mainly to get the better tessellator code. - -- The osmesa driver builds and should work on Windows as well as - any other platform. - -- The Windows driver (in src/Windows) builds and runs at least at - a minimal level. I modified this driver to work with the new - Mesa 4.0 code and driver architecture, but I did not do a great - deal of optimization and testing. There are many opportunities - for optimization, many of which can be done by coding more specific - paths for the rasterizers. See src/osmesa/osmesa.c for some good - examples. - -- There is DirectDraw support in the Windows driver, updated by - Daniel Slater. You'll need to uncomment the #define DDRAW line - in src/Windows/wmesadef.h and add ddraw.lib to the list of libraries - in src/Makefile.win. On some systems, you will acheive significantly - higher framerates with DirectDraw. - -- Some of the more specialized code like FX drivers, stereo, and - parallel support isn't compiled or tested. I left much of this - code alone, but it may need some work to get it 'turned on' again. - -- No assembly code is compiled or assembled. Again, this may need - some work to turn it back on or use it again. +Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same +directory. The libs and demos build separately, so if you do not care +about the demos or GLUT, you only need to unzip MesaLib. If you unzip +more than one ZIP file, they all need to be unzipped into the same +directory. Don't worry, you will not overwrite anything. + +The Windows build system uses Microsoft Visual Studio. Project files +for a specific version of Visual Studio are in their own directory in +the top-level "windows" directory. For example, Visual Studio 8 files +are in windows/VC8. + +Support has been dropped for versions of Visual Studio prior to 8. The +main reason is because Microsoft now provides a free compiler and +developer environment. Visual Studio Express can be found at + +http://msdn.microsoft.com/vstudio/express/visualc/default.aspx + +You'll also need the Platform SDK. Instructions for obtaining and +using the SDK with Visual Studio Express can be found at + +http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/ + +If you are stuck using VC6 or VC7, you may start with these project +files, but you may need to modify them to reflect changes in the +Mesa source code tree. If you sucessfully update the project files, +please submit them to the author of this document so that they may +be included in the next distribution. + +The project files to build the core Mesa library, Windows Mesa +drivers, OSMesa, and GLU are in the mesa directory. The project files +to build GLUT and some demo programs are in the progs directory. + +Makefiles are no longer shipped or supported, but can be generated +from the projects using Visual Studio. + + +Windows Drivers +------- ------- + +At this time, only the GDI driver is known to work. Most of the demos +in progs/demos should work with this driver. + +Source code also exists in the tree for other drivers in +src/mesa/drivers/windows, but the status of this code is unknown. + +The GDI driver operates basically by writing pixel spans into a DIB +section and then blitting the DIB to the window. The driver was +recently cleaned up and rewitten and so may have bugs or may be +missing some functionality. The older versions of the CVS source may +be useful in figuring out any problems, or report them to me. + +To build Mesa with the GDI driver, build the mesa, gdi, and glu +projects in the Visual Studio workspace found at + + windows/VC8/mesa/mesa.sln + +The osmesa DLL can also be built with the osmesa project. + +The build system creates a lib top-level directory and copies +resulting LIB and DLL files to this lib directory. The files are: + + OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB + OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL + +If the MesaDemos ZIP file was extracted, the DLL files are also copied +to the demos directory. This facilitates running the demos as described +below. + + +GLUT and Demos +---- --- ----- + +A Visual Studio workspace can be found at + + windows/VC8/progs/progs.sln + +It can be used to build GLUT and a few demos. The GLUT lib and DLL +are copied to the top-level lib directory, along with the Mesa libs. + +The demo build system expects to find the LIB files in the top level +lib directory, so you must build the Mesa libs first. The demo +executables are placed in the demos directory, because some of them +rely on data files found there. Also, the Mesa lib DLL's were copied +there by the Mesa lib build process. Therefore, you should be able to +simply run the demo executables from the demo directory. + +If you want to run the demos from the Visual Studio, you may have to +change the startup directory and explicitly state where the executables are. + +You may also build all the demo programs by using a makefile. Go to +the progs/demos directory and make sure you have executed VCVARS32.BAT +or whatever setup script is appropriate for your compiler. Then, + + nmake -f Makefile.win + +should build all the demos. + + +Build System Notes +----- ------ ----- + +VC6 (not actively supported) +--- + +Visual Studio 6 does not recognize files with the .cc extension as C++ +language files, without a lot of unnatural tweaking. So, the VC6 +build process uses custom build steps to compile these files in the +GLU library. + +Two additional configurations are provided, Debug x86 and Release x86 +that activate the shader code compilation by defining SLANG_86. It is +unknown if and how this works. + +VC7 (not actively supported) +--- + +The above-mentioned .cc problem does not exist in this version. + +VC8 +--- + +No notes. + + +General +------- + +After building, you can copy the above DLL files to a place in your +PATH such as $SystemRoot/SYSTEM32. If you don't like putting things +in a system directory, place them in the same directory as the +executable(s). Be careful about accidentially overwriting files of +the same name in the SYSTEM32 directory. + +The DLL files are built so that the external entry points use the +stdcall calling convention. + +Static LIB files are not built. The LIB files that are built with are +the linker import files associated with the DLL files. + +The si-glu sources are used to build the GLU libs. This was done +mainly to get the better tessellator code. + +To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE +to the project settings. You will also need to edit src/mesa.def to +change all the gl* symbols to mgl*. Because this is easy to do with a +global replace operation in a text editor, no additional mangled +version of mesa.def is maintained or shipped. If you have a Windows-related build problem or question, it is probably better to direct it to me (kschultz@users.sourceforge.net), -rather than directly to the other Mesa developers. I will help you -as much as I can. I also monitor the Mesa mailing lists and will -answer questions in this area there as well. +rather than directly to the other Mesa developers. I will help you as +much as I can. I also monitor the Mesa mailing lists and will answer +questions in this area there as well. Karl Schultz