[Mesa-dev] Janitorial work: no more intel_context.[ch]; tidying

[Alan Coopersmith]

On 10/ 2/13 01:27 PM, Ian Romanick wrote:
> On 10/02/2013 12:51 PM, Matt Turner wrote:
>> On Wed, Oct 2, 2013 at 11:02 AM, Ian Romanick <idr at freedesktop.org> wrote:
>>> (Adding Alan to the CC list.)
>>>
>>> On 10/01/2013 10:51 PM, Vinson Lee wrote:
>>>> On Mon, Sep 30, 2013 at 10:21 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>>>> On 09/27/2013 06:24 PM, Emil Velikov wrote:
>>>>>> * With the recent split of the intel driver codebase, the new i965
>>>>>> headers has been getting a bunch of #pragma once over the standard
>>>>>> #ifndef _HEADER_H_... Are those intentional ?
>>>>>
>>>>> Yup, that's intentional.  "#pragma once" doesn't require inventing a
>>>>> unique #define name, is less typing, and is faster on some compilers.
>>>>>
>>>>> I actually forgot that it wasn't standard.  It's supported basically
>>>>> everywhere, though, so I'd be really shocked if it caused problems.
>>>>
>>>> Oracle Solaris Studio does not support "#pragma once".
>>>
>>> Is there *any* reason to use that compiler over GCC?  This isn't the
>>> first time that we've discovered it to be lacking some feature that GCC,
>>> clang, and Visual Studio all support. :(
>>
>> Before we go down this rabbit hole -- Vinson said it doesn't support
>> #pragma once. He didn't say it caused problems. I don't expect it is,
>> since we're already using it and have been for a long time.
>>
>> It probably just means that you have to to #pragma once along with the
>> standard #ifndef ... #endif wrapper.

Do the headers contain anything that breaks if they're read multiple times?
If the #pragma once is ignored, does everything just work?

> Understood.  The changes in this patch series use only the pragma, and
> we've identified some benefits of that approach.  I'd like to have those
> benefits, but this compiler seems to stand in the way.  We've had the
> "do we need to support this compiler" for other compilers in the past.
> Sometimes the answer is yes, and sometimes the answer is no.

There's the benefit you always get of another unique set of compiler warnings
helping find bugs - some will overlap other compilers, some won't - how many
will be useful is hard to guess.

And if there were any Mesa users who cared about performance of the software
rasterizer on recent SPARC systems, the Solaris Studio compiler is usually
ahead of gcc since they work with the CPU designers during development.

As a Solaris package maintainer, I can say that we do like to keep stuff
running with Solaris Studio when we can, since we can get direct support
for that if compiler issues occur, but looking in our current Mesa 9
packages I see we're using gcc to build those already, so I can't claim it's
that essential to us in shipping Mesa here.   (I don't remember why gcc is
used here, I would have to ask Niveditha, who maintains our Mesa packages.)

-- 
	-Alan Coopersmith-              alan.coopersmith at oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc