On 2/20/08, Eric Anholt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-20 at 03:25 +0900, José Fonseca wrote: > > On 2/20/08, Ian Romanick <[EMAIL PROTECTED]> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Keith Whitwell wrote: > > > | Ian Romanick wrote: > > > |> José Fonseca wrote: > > > |> | Microsoft compilers don't support C99 syntax. The only native windows > > > |> | compilers that support C99 syntax are mingw32-gcc and Intel C/C++ > > > |> | compiler, but we can't seriously support windows platform by > > > targeting > > > |> | these compilers alone and leave msvc out. > > > |> > > > |> In a word, NO. Frankly, I don't care to be restricted to 20 year old C > > > |> syntax just because Microsoft doesn't care to support the 10 year old C > > > |> syntax. > > > | > > > | Well, in the core parts of gallium this will hold. For the Cell driver > > > | it doesn't matter so much... > > > | > > > | It's hardly ideal but we're basically grownups here and can probably > > > | take it in our stride, especially given that the same restrictions have > > > | been historically enforced in core Mesa. > > > > > > But this has not been the case in the hardware driver code. Isn't this > > > code being folded into gallium (i.e., i965simple)? In that code we > > > routinely use variadic macros, C99 array initializers, and C99 structure > > > initializers...and it makes the code better. > > > > It actually was when I tried to compile this code with msvc and saw > > all the compile errors and all the necessary effort to fix it that I > > decided to write this thread. Basically, using -stc=c99 with gallium > > code hides this problem until it is quite big. > > Wait, are you saying that you're going to be enforcing msvc > compatibility in the drivers as well? I would strongly object to that.
On the drivers we care about, e.g., i965simple, I'm afraid it will have to be so... Drivers that third-parties create, or drivers we maintain but are clearly Linux only (e.g., cell), there is no point to enforce anything. Also the winsys drivers are platform specific, so they can use whatever features the platform they target have. C99 syntax is useful, and I admit that enforcing C89 even for the sake of portability is retrograde, nevertheless the C99 syntax is mostly syntactic sugar: - you can replace variadic macros with inline functions is most common uses - named strucuture initializers help reading, but you can achieve the same thing using a simple comment on each member. - you can easily avoid middle-of-scope variables declarations IMO, the best C99 feature has are library things like stdint.h types. But for those we can and we do provide equivalent definitions in the platforms that lack it. Also, if people care so deeply for C99, it might be worth considering C++, as it is supported. Even though for Windows Kernel mode, almost every single C++ feature is not advisable (http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx). So, at the of the day, you can only use pretty much what C99 gives you. Another suggestion given on IRC yesterday is compiling C99 code as C++ on MSVC. I have strong suspicion that it will bring a world of pain when linking to code outside gallium, but it is worth to check it. But for the meanwhile, please refrain of using C99 syntax on: - src/mesa/state_tracker/*.h - src/gallium/include - src/gallium/auxiliary - src/gallium/drivers/i915simple - src/gallium/drivers/i965simple It is OK to use C99 in - src/mesa - src/gallium/winsys - src/gallium/drivers/cell - etc. I'll soon disable -std=c99 and enable -pedantic inside src/gallium so that people get warnings when using c99 features. Again, I'm sorry to have to play the role of bad guy here. However, Windows support on gallium was an objective from the very beginning, and cross-platform portability implies sacrifices. Of course that, for those who don't care about windows portability, you're basically being asked to give up something without receiving nothing extra in return... But don't forget that the gallium source code was almost entirely coded by TG so far, so you *did* actually receive something already. Code doesn't come out of thin air -- it costs money. So I think it's not unfair to ask you in name of cooperation to do such sacrifice. Jose ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
