-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 José Fonseca wrote: > On Sat, 2009-09-05 at 14:04 -0700, Ian Romanick wrote: >> >> José Fonseca wrote: >>> On Fri, 2009-09-04 at 13:01 -0700, Ian Romanick wrote: >>>> >>>> Brian Paul wrote: >>>> >>>>> I'll fix these. >>>>> >>>>> Perhaps we should prefix or suffix all the lexer tokens with "T_" or >>>>> something like that to avoid collisions. Ian? >>>> Could we just fix it to not include broken Windows header files? >>> I doubt. Windows headers have use beyond polluting the global namespace. >> Is Mesa using this definition of POINT or SIZE in someway that I'm not >> aware of? > > First, sorry for my excessive cynicism above. I didn't realize you're > suggesting only not including the windows headers that define these > symbols, but I shouldn't come so hard regardless. > > The problem with the windows headers is that they cannot be > cherry-picked. One has to include the top windows.h header which will > include the headers that define the whole breadth of the Win32 API. > Including another header will either include the windows.h header at the > top, or will cause compilation failures. There is a pre-processor flag > called WIN32_LEAN_AND_MEAN which skips the inclusion of some rarely used > headers from windows.h. We already define this flag trhoughout > Mesa/Gallium, but it really doesn't change much -- the ammount of stuff > brought by windows.h is still huge. > > The point here is that, even if Mesa isn't using POINT or SIZE, as long > as there is some other need for windows headers there is no way to mask > out the POINT and SIZE symbols. > > There are two major reasons for windows.h to be included almost > everywhere: > > - GL.h on windows depends on some types / qualifiers defined inside > windows.h. Although it is possible to eliminate this dependency, this > most often breaks the code that legitimately needs windows.h, or causes > problems with different compilers, due to small variations in the way > these types/qualifiers are defined in MSVC, MinGW, and other compiler > toolchains. > > - windows.h defines compiler intrinsics for things like atomic > operations, which we want to use directly so that they are inlined in > the code, for performance. > > So, although it might be possible to avoid the inclusion of windows > headers in a particular module with some effort, as a global strategy > for Mesa and Gallium, trying to avoiding windows headers everywhere is > just not sustainable.
It never fails to amaze me the lengths to which Microsoft goes to prevent people from being able to write portable code. > Using unique prefixes for global symbols is a much better strategy, as > it not only protect us from the symbol collisions of the windows > headers, it also makes us more future-proof, against new platforms or > the inclusion of third party components. For "regular" code, I would be inclined to agree. However, these are the token defines for the Bison parser. Adding a prefix / suffix to the tokens makes the code really dreadful to read. ATTRIB_statement: ATTRIB IDENTIFIER '=' attribBinding vs. ATTRIB_statement: ATTRIB_TOK IDENTIFIER_TOK '=' attribBinding through the whole parser. Yuck. Once the GLSL compiler front-end gets moved to flex / bison, it will be even worse. I guess we can put band-aids on this for now, and I'll try to find a more complete solution for the future parser work. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqkcTcACgkQX1gOwKyEAw9ZkACfR2NECskh1QcCoPuODU9OgUdL m0cAn13thsz5SW2jAJlEh+YOhAnR8Dcd =NcJE -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
