4 Last Updated: Sunday, September 19th, 1999 - tjump@tertius.com
\r
8 - Updated for Mesa 3.1beta3/CVS. Debug and Release command-line builds of
\r
9 Mesa, fxMesa, GLU, GLUT and all sample programs DLL-based. Manual
\r
10 executions tests with minimum requisite results (aka: things looked like
\r
11 I expected them to).
\r
13 What did you expect, complete regression testing maybe?
\r
15 - NASM build support. Any file in the project coded as a .S file will
\r
16 automatically be recognized and built as a NASM-source assember file.
\r
18 To enable building using NASM, set the environment variable NASM to
\r
19 indicate that command to execute to run nasm on a file. If NASM is in
\r
20 your command search path then all this needs be set to is 'nasmw' -
\r
21 otherwise you will need to include the complete drive and directory path.
\r
23 NASM may be retrieved here: http://www.web-sites.co.uk/nasm/
\r
25 - DevStudio projects suspended for compatability reasons: projects modified
\r
26 by DevStudio 6 are not compatible with DevStudio 5.
\r
28 These will slowly be rebuilt and put into CVS as I can.
\r
30 - Build environment change: The Glide SDK is no longer assumed to be in
\r
31 the global INCLUDE/LIB environment vars, it is required that you set the
\r
32 value 'GLIDE2X' as either an environment variable pointing to your Glide
\r
33 SDK install directory or that you configure that as a build option to
\r
34 nmake.exe when building fxmesagl32. Examples:
\r
36 nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x fxmesagl32
\r
40 nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x allfx
\r
44 nmake /f nmake.mak GLIDE2X=g:\sdk\glide2x progs.3dfx.demos
\r
46 The DevStudio workspace files for 3Dfx OpenGL require the definition of
\r
47 GLIDE2SDK as an environment variable pointing to where your copy of the
\r
48 Glide SDK has been installed. Adding this to your AUTOEXEC.BAT would do
\r
49 so (change the directories to match):
\r
51 SET GLIDE2SDK=G:\SDK\GLIDE2X
\r
55 These build files are provided as-is and are submitted to be included with
\r
56 the "Mesa 3-D Graphics Library" package as (currently) maintained by Brian
\r
57 Paul. These project build files are free software; you can redistribute it
\r
58 and/or modify it under the terms of the GNU Library General Public License
\r
59 as published by the Free Software Foundation; either version 2 of the
\r
60 License, or (at your option) any later version.
\r
62 These project files are distributed in the hope that they will be useful,
\r
63 but WITHOUT ANY WARRANTY; without even the implied warranty of
\r
64 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library
\r
65 General Public License for more details.
\r
67 You should have received a copy of the GNU Library General Public License
\r
68 along with this library; if not, write to the Free Software Foundation,
\r
69 Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
\r
71 *** Maintenance Responsiblity and Technical Support
\r
73 While these files are now part of the Mesa core distribution please do NOT
\r
74 contact Mr. Paul for help with them if you encounter problems as he can't
\r
75 help you (currently). I will, however, attempt my straightforward best in
\r
76 assisting anyone with using these files on their system. I can NOT
\r
77 guarantee instant responses owing to other responsiblities, but I do try
\r
78 dang hard to answer any mail w/in 24 hours. I may be contacted at the
\r
79 above email address for the forseeable future.
\r
82 mailto://tjump@tertius.com
\r
83 http://www.tertius.com/tjump
\r
85 *** General Information
\r
87 These build files facilitate convenient building of many variants of Mesa,
\r
88 both as static link libraries (including mesaglu) and as dynamic link
\r
89 libraries that in some cases may be used as "drop-in" replacements for
\r
90 OpenGL32.DLL on both Windows95 and Windows NT.
\r
92 The construction of the Win32 command-line build files and projects has
\r
93 been something of a pet project of mine, and is based upon my own
\r
94 "standard" Win32 build environment as supplied by the "nmake.mif" file.
\r
95 They have been tested under Windows95 OSR2, Windows NT 4.0SP3, and Windows
\r
96 NT 5.0 beta 1. The libraries that they generated have been tested (via the
\r
97 demo programs) in a *limited* fashion on the above three systems, including
\r
100 The reason I went with command-line build environment instead of the more
\r
101 convenient IDE-based project files is for two reasons: 1. These appear to
\r
102 have some amount of portability between versions (the nmake syntax hasn't
\r
103 changed much since Microsoft C 7.0) while the IDE project files seem to
\r
104 change drastically each version. and 2. These are readable with any ascii
\r
105 editor and such are better self-documentation of the file relationships for
\r
106 more people such that it will facilitate supporting other Win32 compilers.
\r
108 While these files only deal with building for x86 targeted code it *should*
\r
109 be possible to add the necessary logic to them to build for the other MSVC
\r
110 supported CPU targets, I simply have no hardware to test them on nor the
\r
111 alternative compilers to build with.
\r
113 *** Prerequisites for use
\r
115 1. You must have a 32-bit Microsoft compiler installed. I have tested
\r
116 this with Visual C 5.0 (SP3) and Visual C 4.2, but with minor
\r
117 (possibly no) modification to the nmake.mak and nmake.mif files this
\r
118 sequence should work on Visual C 2.0 also. The workspace files
\r
119 (mesalib.dsw and mesademos-*.dsw) and their included project files
\r
120 (*.dsp) are specific to the DevStudio IDE - I have made no attempt at
\r
121 building a VC4 IDE project set as I do not use that any more. Note
\r
122 that the VC workspace files NO LONGER use NORE are dependant upon the
\r
123 nmake.mak and nmake.mif files for construction of definition (*.DEF)
\r
124 and resource (*.RC) files.
\r
126 *** Visual C 4.x Users Warning ****
\r
128 Note that early editions of VC4 do NOT have header files current enough
\r
129 for use building this code base. If you are using VC4 you will either need
\r
130 to get an update to version 4.2 *or* you may download the Platform SDK
\r
131 directly from Microsoft's web site (www.microsoft.com) and update your
\r
132 build environment that way.
\r
134 *** Visual C 4.x Users Warning ****
\r
136 2. You must have the PATH, INCLUDE, and LIB environment variables set
\r
137 properly. With VC5 you can easily get this by executing the VCVARS32.BAT
\r
138 file that was created for you upon installation. It is found in the
\r
139 DevStudio\VC\BIN directory, wherever you installed DevStudio. VC4 provides
\r
140 a similar batch file in it's BIN directory also.
\r
142 3. (optional) If you're going to build for 3Dfx/Voodoo you will need to
\r
143 have previously installed the Glide SDK version 2.3 or later, if I
\r
144 recall. This may be retrieved from www.3dfx.com for no money and some
\r
145 download time. ;-) These build files assume that you have the Glide SDK
\r
146 added to the respective environment variables (LIB and INCLUDE).
\r
148 4. (optional) If you're going to build for S3/Virge you will need the S3
\r
149 Developers Toolkit which may be downloaded from www.s3.com for the price of
\r
150 registering on-line and some time. NOTE: I can build the s3mesa.dll file to
\r
151 completion, however the compilation of s3mesa.c currently generates a large
\r
152 amount of compiler warnings and between that and the fact that I can not at
\r
153 all test it I can make no claims to it's ability to execute. Again, like
\r
154 the 3Dfx version before this, these build files assume you have the S3Dtk H
\r
155 and LIB files in the path of their respective environment variables.
\r
156 Note 2: As of Mesa3.0beta6 I have build files, both command-line and IDE,
\r
157 which should be able to build the s3mesa code base if it weren't for updates
\r
158 being required in the S3 DD code support (Mesa-3.0/src/s3 directory).
\r
160 I advise putting any include and lib files for secondary toolkits (Glide,
\r
161 S3Tk, whatever) in their respective environment variables *before* the
\r
162 Microsoft-assigned default values.
\r
164 *** FAQ: Frequenty Asked Questions and Other Important Information ***
\r
166 - When running the 3Dfx demos under Windows NT, they crash on exit, what's
\r
169 This is apparently a problem in Glide itself. The workaround is to go to
\r
170 your C:\WINNT\SYSTEM32 directory and rename the file FXOEM2X.DLL to
\r
171 FXOEM2X.DL_ to prevent Glide from loading and initializing it upon
\r
172 startup. This is known to be an issue with cards that do not have "TV
\r
173 out" and is known to cause crashes on Diamond Monster II 8M and 3Dfx
\r
174 Reference boards, all using 3Dfx Reference Drivers version 2.53. Other
\r
175 hardware/driver combinations will also likely exhibit this behavior.
\r
177 - I'm having a problem building Mesa for static library linking.
\r
179 This was caused by some incomplete testing on my part, and a fix is now
\r
180 available in the form of an add-on to the base Mesa 3.0 release. The
\r
183 via FTP download from: iris.ssec.wisc.edu
\r
184 you want to go here: /pub/Mesa/patches_to_3.0/
\r
185 you want to get file: Mesa-3.0-w32-static-fixes.tar.gz
\r
187 This required a minor addition to INCLUDE/GL for a clean solution, the
\r
188 file "include/gl/mesa_wgl.h" is automatically included by
\r
189 "include/gl/gl.h" when a Win32 non-DLL build is in progress to provide
\r
190 prototypes for the various wgl functions.
\r
192 The only remaining hitch in this setup is that the 3Dfx build is not yet
\r
193 running as a static build, because of problems with conflicts in
\r
194 existance of the various GDI functions like ChoosePixelFormat,
\r
197 Anyway, the "allstatic" target now works as expected and builds all
\r
198 book/sample/demos programs to boot. ;^)
\r
200 - How do I get fxMesa to render in a window on the desktop instead of only
\r
203 Use the Microsoft Windows fxMesa-in-a-window hack!
\r
205 Seriously, if you want fxMesaGL to render using the 3Dfx Voodoo1 or
\r
206 Voodoo2 hardware into a window on the desktop then all you need to do is
\r
207 set the MESA_WGL_FX environment variable to anything other than
\r
208 "fullscreen" and it will render into a window. If you wish to go
\r
209 fullscreen then you only need to NOT have the environment variable, or
\r
210 have it set to "fullscreen". You may also switch at runtime between
\r
211 fullscreen-mode and windowed by pressing ALT-ENTER on the keyboard
\r
212 (unless the application using Mesa does something with those keystrokes,
\r
215 As of 8/13/98 this should be running a LOT better for more people as a
\r
216 low-compatability item was cleaned up which prevented it from working on
\r
217 many (most?) display drivers under Windows 9x.
\r
219 - I have my 3Dfx card hooked to it's own monitor and I want the output to
\r
220 stay on even if I switch to another program, is this possible?
\r
222 If the Glide environment variable SST_DUALHEAD is set to '1' then fxMesa
\r
223 will never disable the Voodoo output on a Voodoo1 or Voodoo2 display
\r
224 regardless of whether the fxMesa application is "current" or not. This
\r
225 works regardless of whether it's rendering using the window hack
\r
226 mentioned above or not.
\r
228 - I want to run the Mesa demos on my Intel740 card using it's own OpenGL
\r
229 acceleration, how do I do this?
\r
231 Build GLUT standalone for use with system OpenGL and GLU drivers!
\r
233 The Command-line project supports building all test/demo programs against
\r
234 these drivers also! This allows you full use of GLUT on Windows using
\r
235 hardware accelerated OpenGL. Wheee! This includes the "3dfx/demos"
\r
236 directory of which only two programs will not run on "standard"
\r
237 opengl. Note that there are a few of the sample programs which will NOT
\r
238 work without Mesa as they directly call into Mesa instead of using the
\r
239 extension mechanism.
\r
241 *** Included programs that exhibit unfortunate or bad behavior
\r
243 - demos/bounce - doesn't run on high-colors screens? It's requesting an
\r
244 INDEX display from GLUT and that fails on my true-color desktop. Changing
\r
245 this to _RGB let's the program work, but it doesn't display
\r
246 properly. This is probably just an idiosyncracy of my machine though, as
\r
247 if I test the program using GLUT for System OpenGL on my Intel740 OpenGL
\r
248 accelerated machine it's just hunky-dory.
\r
250 - demos/glutfx - runs, but crashes on exit (but not on my Intel740 machine)
\r
252 - demos/texobj - runs, but crashes on exit if ESC is pressed. Exits cleanly
\r
253 if the Close box on the window frame is pressed with the mouse. Go figure.
\r
255 - book/aaindex - doesn't run, can't get pixel format, because it wants an
\r
256 INDEX display maybe (but is okay on my Intel740 machine)?
\r
258 - most of the book/* demos don't respond to ESC being pressed.
\r
260 - 3dfx/demos/* - all demos run, however they all crash on exit. I've traced
\r
261 this so far as to determine the call it's happening with. The crash comes
\r
262 from within Glide during the processing of the grGlideShutdown() call, as
\r
263 in invalid memory reference exception. I'm wondering if this is because
\r
264 of some state or processing not being completed before the call. Dunno,
\r
265 but putting grSstIdle() in just before grGlideShutdown() does NOT fix the
\r
268 - 3dfx/demos/tunnel2 - does not run on my system even with SLI mode
\r
269 disabled. Hmmmm, maybe I need to disconnect my Voodoo2 cards?
\r
271 *** Important Notes and Changing Default values
\r
273 - The optimizer settings have been manually reworked in both command line
\r
274 and DevStudio IDE files to hopefully prevent possible irrational code on
\r
275 the part of the code generator. Formerly, it was configured for "/Ox",
\r
276 now it is configured for safer handling at a slight potential performance
\r
277 cost. This may not be required for Visual Studio 6 but I can't test that
\r
280 - These files build with the code targeted for Pentium processors and
\r
281 8-byte structure padding.
\r
283 - The IDE-built programs seem to be "happier" in that the command line
\r
284 build of the 3Dfx demo "fire" will grenade on exit (?). Otherwise pretty
\r
285 much everything may be built with either interface.
\r
287 - The currently configured Mesa version is 3.1, and MesaDemos version is
\r
288 the same. To change this permanently you will need to edit NMAKE.MAK and
\r
289 change the lines that look like this (they start o/a line 116):
\r
291 # Currently, Mesa is at rev 3.1 ...
\r
293 !IF "$(MESAVER)" == ""
\r
297 # used in building all of the resource files for the Mesa DLLs
\r
299 !IF "$(MESAFILEVER)" == ""
\r
300 MESAFILEVER=3,1,0,0
\r
303 - Currently the build files are configured to be used from a Win32
\r
304 directory that is included inside the main Mesa-3.1 heirarchy.
\r
306 - The build files are smart enough to find the files for the core lib, glu,
\r
307 glut, and the various demo programs if they are unpacked in the current
\r
308 Mesa-3.1 heirarchy, like this:
\r
318 \Mesa-3.1\3Dfx\demos
\r
320 ... should work. This arose because my initial build tests for the
\r
321 demo files were done before MesaDemos 2.6 had been released.
\r
323 - With the exception of the static link libraries generated by this file
\r
324 set (mesagl.lib, mesaglu.lib, mesaglut.lib) all DLLs and executables are
\r
325 built against the "Multithreaded DLL" runtime - this means that they
\r
326 require MSVCRT.DLL or MSVCRTD.DLL in the path to execute.
\r
328 ** CHANGED 8/11/98 ***
\r
330 Note also that the demos are all built aginst the "OpenGL32, GLU32, and
\r
331 GLUT32" and as such they are fairly agnostic wrt: building against Mesa
\r
332 for CPU-rendering, Mesa-for-3Dfx, Mesa-for-S3, or System OpenGL.
\r
334 If you want to build them for use on your system and your display card
\r
335 provides full OpenGL acceleration (Permedia, Intel740, Intergraph,
\r
336 whatever) then you only need to build GLUT prior to building any of the
\r
337 demo programs. For convenience, the GLUT project is included in each of
\r
338 the demo projects Workspace files for the DevStudio IDE builds BUT it is
\r
339 not automatically built - you still need to build it first manually.
\r
341 Note that if you have GLUT already installed on your system (gl/glut.h in
\r
342 yoru INCLUDE path, glut32.lib/glut32d.lib in your LIB path, and the DLL
\r
343 in your PATH) then you do NOT need to build GLUT prior to the test
\r
346 - The 3Dfx build of Mesa has primarily been tested with Quake 2 and it runs
\r
347 (mostly) fine on my PC (take that for what you want it)...
\r
349 ** CHANGED 8/11/98 ***
\r
351 There is still something going on that causes Glide to crash on shutdown,
\r
352 when I run fxMesa under Windows NT, however it does not appear to occur
\r
353 under Windows 9x on either Voodoo1 or Voodoo2 cards. *sigh*
\r
355 - I can not test the S3 build as I have no machines available with Virge
\r
356 based display cards.
\r
358 - The multithreaded test code is *not* built as it requires pthreads and I
\r
359 have as of yet spent not time trying to get that running. The latest word
\r
360 that I saw WRT threading support on win32 was that they are intending to
\r
361 support it natively within Win32 - so I'm waiting it out until they get
\r
364 - Similarly, the 'xdemos' are not currently built because I haven't gotten
\r
365 around to building the client libs for native win32 and getting it all
\r
370 All final output files (DLL/LIB) are placed in the Mesa-3.1/lib directory,
\r
371 with the exception of the fxMesaGL32 build which is placed in
\r
372 Mesa-3./lib/FX and the executable images which are placed in their source
\r
375 To be able to execute the various test programs, you will need to copy the
\r
376 requisite DLL files into the same directory as the EXE files. Note that
\r
377 most of the 3Dfx/demos/* programs WILL run with the non-FX build of Mesa -
\r
378 just very slowly. The two programs which are hard-linked with the FX build
\r
379 and will not run without it are "glbpaltx" which uses "gl3DfxSetPaletteEXT"
\r
380 directly instead of via the extensions mechanism and "tunnel2" which uses
\r
381 "fxMesaSelectCurrentBoard" API for selecting between multiple 3Dfx cards
\r
382 installed in one system. Likewise, "paltex" directly uses the
\r
383 "glColorTableEXT" extension and thus may not run on anything except
\r
384 Mesa. If these applications used the proper extension mechanism they could
\r
385 then be used on more than "just" fxMesa to good effect (for example, the
\r
386 rest of the "3Dfx/demos" run just peachy on the Intel740 card in my test
\r
387 machine) under WinNT.
\r
389 Because I'm anal about my computer and it's organization, and I like to
\r
390 prevent collision between builds, each of the subprojects has their own
\r
391 intermediate file directory inside .\win32\release (for example, when
\r
392 building mesagl.lib all of it's intermediate files will be found in
\r
393 .\win32\release\lib.mesagl). This makes it very easy to cleanup as you
\r
394 only need to remove .\win32\release.
\r
396 *** Okay, Enough, how do I build with this stuff already Ted!
\r
398 Okay, no major calamity here. The basic way to use the project file is to
\r
399 call it via NMAKE from the command line. The format is:
\r
401 nmake[.exe] /f nmake.mak [options] [target]
\r
403 The most likely [options] values you will use may be any combination of the
\r
407 USE_CRTDLL=1 or USE_CRTDLL=0
\r
409 Note that all three of these options are OFF by default.
\r
411 The [target] includes but is not limited to the following (for full details
\r
412 please peruse the NMAKE.MAK and NMAKE.MIF files - but be warned that
\r
413 NMAKE.MIF is rather large and sometimes hard to follow):
\r
415 --- convenience targets ---
\r
417 all - builds everything
\r
418 libfiles - builds all linking library files
\r
419 progs - builds all executable images
\r
421 --- library files, static and dynamic ---
\r
423 mesagl - static lib build of Mesa core.
\r
424 mesaglu - static lib build of MesaGLU core.
\r
425 mesaglut - static lib build of Mesa GLUT core.
\r
427 mesagl32 - dynamic lib build of Mesa core.
\r
429 mesaglu32 - dynamic lib build of GLU core, generates
\r
430 GLU32.DLL and/or GLU32d.DLL.
\r
432 mesaglut32 - dynamic lib build of GLUT core, generates
\r
433 GLUT32.DLL and/or GLUT32d.dll.
\r
435 --- hardware accelerated mesa builds ---
\r
437 fxmesagl32 - builds Mesa for use on top of the 3Dfx
\r
440 s3mesagl32 - builds mesa for use on top of the S3
\r
441 'S3Tk' runtime libs.
\r
443 --- executable images ---
\r
445 progs.book - builds all programs in \book directory
\r
446 progs.demos - builds all programs in \demos directory
\r
447 progs.samples - builds all programs in \samples directory
\r
449 These targets generate all of the programs in their respective
\r
450 directories and link the executables against OpenGL32.DLL,
\r
451 GLU32.DLL, and GLUT32.DLL (or their debug equivalents).
\r
453 progs.3dfx.demos - builds all programs in \3dfx\demos directory
\r
455 This target generates the 3Dfx/Demo executables, linking them
\r
456 against GLUT32.DLL, GLU32.DLL, OPENGL32.DLL and are thus NOT
\r
457 hard-bound to using Mesa per-se as you can simply NOT build the
\r
458 Mesa core and GLU libraries.
\r
460 --- Microsoft/SGI OpenGL-based GLUT and Demo program builds ----
\r
462 *** IMPORTANT SAFETY TIP: If you're going to build these variants of
\r
463 GLUT then DO NOT build any other target libraries in this package
\r
464 first, OR from the command line run the "nmake /f nmake.mak clean"
\r
465 command first! This is because generation of the GLUT for SGI
\r
466 OpenGL target libraries conflicts in naming with the static build
\r
467 libraries of Mesa and it's supporting GLUT build.
\r
469 Currently, you may build GLUT as either GLUT32.DLL or GLUT.DLL for
\r
470 use running against either Microsoft or SGI OpenGL for Window,
\r
471 respectively. This allows for the general use of GLUT 3.7 on Windows
\r
472 systems with fully compliant OpenGL.
\r
474 You can build the GLUT DLL files either with the command line by
\r
475 issuing either of these commands:
\r
477 nmake /f nmake.mak glut.sysgl
\r
481 nmake /f nmake.mak glut.sgigl
\r
483 OR by using the DevStudio MesaLib Worksapce build the GLUT_SGIGL or
\r
484 GLUT_SYSGL projects within the DevStudio IDE.
\r
486 Unfortunately, the only way to build the test programs against this
\r
487 build of GLUT is via the command line, and I will NOT be making
\r
488 duplicate demo program projects for the IDE as it's just not worth it,
\r
491 To build the test programs against either MS or SGI OpenGL, you do so
\r
492 via either of these two commands:
\r
494 nmake /f nmake.mak progs.sysgl
\r
498 nmake /f nmake.mak progs.sgigl
\r
500 To use the GLUT-for-system-OpenGL in your own programs, you need to do
\r
501 three things by way of preparation, after building GLUT of course:
\r
503 1. Copy include\gl\glut.h to somewhere in your %INCLUDE% path, one
\r
504 likely candidate location would be in your
\r
505 "DevStudio\VC\INCLUDE\GL" directory.
\r
507 2. Copy the linking libraries to somewhere in your %LIB% path, one
\r
508 likely candidate location would be in your "DevStudio\VC\LIB"
\r
509 directory. The linking libraries you need to copy are as
\r
512 .\Release\GLUT32.LIB
\r
517 3. Copy the runtime libraries to somewhere in your %PATH%, one
\r
518 likely candidate location would be in WINDOWS\SYSTEM. the files
\r
519 that you should copy are as follows:
\r
521 .\Release\GLUT32.DLL
\r
522 .\Release\GLUT32.PDB
\r
525 .\Debug\GLUT32d.DLL
\r
526 .\Debug\GLUT32d.PDB
\r
530 Some examples are in order ...
\r
532 ... build all dynamic-link libs using MSVCRT.DLL for C runtime:
\r
534 nmake /f nmake.mak USE_CRTDLL=1 alldynamic
\r
536 ... To build all library variants and all test and demonstration
\r
537 programs with the default settings you do this:
\r
539 nmake /f nmake.mak all
\r
541 ... to build all static link libs and nothing else you do this:
\r
543 nmake /f nmake.mak allstatic
\r
545 ... to build all non-accelerated dynamic link libs you do this:
\r
547 nmake /f nmake.mak alldynamic
\r
549 ... to build all 3Dfx targeted dynamic link libs you do this:
\r
551 nmake /f nmake.mak allaccel
\r
553 ... to build all S3 Virge targetd dynamic link libs you do this:
\r
555 nmake /f nmake.mak alls3
\r
557 ... to build all libraries, static and dynamic, in all versions
\r
560 nmake /f nmake.mak libfiles
\r
562 ... to subsequently build all demo and test programs you do this:
\r
564 nmake /f nmake.mak progs
\r
566 ... to cleanup all intermediate files you do this:
\r
570 You get the picture. (I hope) ;^) You may also specify specify
\r
571 single targets in a convenient fashion. The rule is simple, any of the
\r
572 above named lib files, static or dynamic, may be built by providing it's
\r
573 name on the command line as the target. Examples:
\r
575 ... to build only Mesa as OpenGL32.DLL ...
\r
577 nmake /f nmake.mak opengl32
\r
579 ... to build only Mesa on top of the 3Dfx Glide API ...
\r
581 nmake /f nmake.mak fxMesaGL32
\r
583 nmake /f nmake.mak fxMesaGL
\r
585 ... to build only Mesa on top of the S3 Toolkit ...
\r
587 nmake /f nmake.mak s3MesaGL32
\r
589 nmake /f nmake.mak s3mesaGL
\r
591 *** Revision history for ./win32 project files
\r
593 1/18/98 - initial cut submitted and included with core mesa
\r
594 2/5/98 - fixed internal dependency within nmake.mif upon there being
\r
595 a $(DEVDIR) variable to make some temporary batch files
\r
596 dependant upon (thanks to Keven T. McDonnell for finding
\r
597 that there was this particular bug). I also updated the
\r
598 build files for 2.6beta6.
\r
599 2/8/98 - added DevStudio workspace and project files for all lib
\r
600 files and some test programs. Updated readme.win32.
\r
601 6/25/98 - initial revision for Mesa 3.0, does not include IDE files,
\r
602 not everything is running. *sigh*
\r
603 7/20/98 - Mesa 3.0beta6 rev of all build files, all libs built and
\r
604 minimally tested, all demo programs built and minimally
\r
605 tested to within limits of my PC. ;^) Eveything looks
\r
606 MUCH better now ...
\r
607 7/30/98 - Minor updates/edits based upon feedback from
\r
608 Eero Pajarre <epajarre@koti.tpo.fi>. These updates include a fix
\r
609 to the Mesa-on-3Dfx build such that Quake-II now runs almost
\r
610 properly on my system. It runs, just *very* slowly and with *no*
\r
611 textures. Hmmm. Doesn't make any difference whether Quake is set
\r
612 to use 8-bit textures or not.
\r
613 8/13/98 - Lots of build cleanups, minor bug fixes in fxwgl.c, and
\r
614 compatability fix in fxapi.c for in-window rendering using 3Dfx
\r
616 8/26/98 - Final revisions for Mesa 3 release checked
\r
617 9/22/98 - Fixed static builds for all but fxMesaGL32 and s3MesaGL32 targets
\r
618 9/29/98 - Reorganized FAQ information and added Added faq entry about Glide
\r
619 bug under NT (crash on exit) and a workaround.
\r
620 11/21/98 - Updated files for Mesa 3.1 beta 1
\r
621 Updated fxMesa window-hack code
\r
622 Updated fxMesa resolution support to handle 1600x1200 & 1280x1024
\r
623 7/9/99 - Rev'd for Mesa 3.1 beta 2
projects / profile / ivi / mesa.git / blob