On Wed, 2008-02-20 at 09:56 +0900, José Fonseca wrote: > 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.
I guess I had been unclear on the gallium plan. If existing DRI drivers get to continue living side-by-side with gallium stuff, then until gallium proves to be a significant win for our chipsets we can go ahead and ignore it, it sounds like. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
