On Sat, 2009-09-05 at 14:04 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > José Fonseca wrote: > > On Fri, 2009-09-04 at 13:01 -0700, Ian Romanick wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> 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. 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. Jose ------------------------------------------------------------------------------ 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
