turnip: Execute ir3_nir_lower_gs pass again
[mesa.git] / docs / README.WIN32
index e16ee4b3a06b4be8d854e3a2e4a8401279c6c527..0f5010ce121c9f1a4e71a496f846b7123175fd00 100644 (file)
 File: docs/README.WIN32
 
-Last updated: Oct 01, 2004 - Karl Schultz - kschultz@users.sourceforge.net
+Last updated: 21 June 2013
+
 
 Quick Start
+----- -----
+
+Windows drivers are build with SCons.  Makefiles or Visual Studio projects are
+no longer shipped or supported.
+
+Run
+
+  scons libgl-gdi
+
+to build gallium based GDI driver.
+
+This will work both with MSVS or Mingw.
+
+
+Windows Drivers
+------- -------
+
+At this time, only the gallium GDI driver is known to work.
+
+Source code also exists in the tree for other drivers in
+src/mesa/drivers/windows, but the status of this code is unknown.
+
+Recipe
+------
+
+Building on windows requires several open-source packages. These are
+steps that work as of this writing.
+
+- install python 2.7
+- install scons (latest)
+- install mingw, flex, and bison
+- install pywin32 from here: http://www.lfd.uci.edu/~gohlke/pythonlibs
+  get pywin32-218.4.win-amd64-py2.7.exe
+- install git
+- download mesa from git
+  see https://www.mesa3d.org/repository.html
+- run scons
+
+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.
 
-Unzip both ZIP files (MesaLib and MesaDemos) into the same directory.
-The libs and demos build separately, so if you do not care about the
-demos, you do not have to unzip that zip file.  But if you do, it does
-need to be unzipped into the same directory as the lib zip file because
-the demos depend on the libs.
-
-The build system has been changed to use Microsoft Visual Studio project
-workspaces and projects.  Makefiles are no longer shipped or supported, but
-can be generated from the projects using Visual Studio.
-
-The workspace and project files were created with Visual Studio 6, so that
-they can be used with VS6 and so that they can also be imported into VS 7.
-
-Details and Notes
-
-- To build the Mesa libraries, open the Mesa.dsw workspace file
-  in the top directory.  You will need to build at least one
-  driver.  Currently, only the gdi and osmesa drivers are available.
-  Select one or the other as the active project and build it.
-  If you want glu, select the glu project as active and build that as well.
-
-- Glut is no longer in the Mesa.dsw workspace.  It is now built in
-  the demo workspace (see below).
-  
-- The build process will create a lib directory in the top directory 
-  and will put the following files there as you build them:
-       OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB
-       OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL
-
-- Some users have reported problems building glu with VS7 after importing
-  and converting the VS6 project files.  The problem is caused by a custom
-  build step that was put in place to work around a problem with VS6 not
-  recognizing .cc files as C++ source files.  It appears that VS7 can be
-  configured to recognize .cc files as C++ files and so it compiles these
-  glu files with the default settings, and does not use settings that are
-  required to compile the files correctly.  The easiest way to solve the
-  problem is to remove the .cc files from the glu project.  This does not
-  delete the files, but removes them from the project so that VS does not
-  try to compile them at all.  This allows the custom build step to compile 
-  the files with the proper settings.
-
-- 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.
-
-- Build the demos by opening the appropriate *.dsw file in the
-  progs directory tree.  For example, to build the demos, use
-  progs/demos/Windows/demos.dsw.  The Windows directory contains
-  the workspace and all the projects for each demo program.  Each
-  project places the executable in the same directory as its source
-  code, which is required for some demos.
-
-- The demo projects also copy the Mesa library DLL files from the lib
-  directory into the same directory as the demo executables, so that
-  the demos use the Mesa libs you just built.
-
-- 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.
-
-- 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.
-  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.
-
-- 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.
-
-
-Karl Schultz
+If you have a Windows-related build problem or question, please post
+to the mesa-dev or mesa-users list.