On Sun, 2009-09-06 at 19:34 -0700, Ian Romanick wrote: > -----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.
Thanks Ian. 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
