Re: [Mesa-dev] glretrace

2010-12-06 Thread tom fogal
Jose Fonseca writes: > I can remove python2.6 dependency as you suggest, but although this > new string formatting method is seldom used it actually makes the > code much more readable and I was hoping to spread its use, so I'd > like you to try one thing first before giving it up: I agree that i

Re: [Mesa-dev] [GLSL] defined expressions

2010-12-06 Thread Carl Worth
On Mon, 06 Dec 2010 20:23:52 +, José Fonseca wrote: > I suppose it is possible for space to be significant on a conditional > expression, e.g., > > #if foo () > > vs > > #if foo There's no significant whitespace here. A function-like macro can be invoked without or without intervening

Re: [Mesa-dev] glretrace

2010-12-06 Thread Jose Fonseca
Hi Tom, I can remove python2.6 dependency as you suggest, but although this new string formatting method is seldom used it actually makes the code much more readable and I was hoping to spread its use, so I'd like you to try one thing first before giving it up: I don't know which Debian releas

Re: [Mesa-dev] glretrace

2010-12-06 Thread tom fogal
Hi José, José Fonseca wrote: FYI, I've extended my apitrace project to be able not only to show a list of GL calls, but also replay them. Neat! The idea is to facilitate reproduction of bugs, help finding regressions, and do it across different platforms. Code is in http://cgit.freedesktop

Re: [Mesa-dev] [GLSL] defined expressions

2010-12-06 Thread José Fonseca
On Fri, 2010-12-03 at 15:37 -0800, Carl Worth wrote: > On Fri, 3 Dec 2010 13:34:09 -0800, Kenneth Graunke > wrote: > > On Friday 03 December 2010 08:01:06 José Fonseca wrote: > > > parser->space_tokens = 1; > > > > > > statement conditional_tokens stanza -- it causes space tokens to be > > > e

Re: [Mesa-dev] LLVM_CFLAGS

2010-12-06 Thread José Fonseca
On Mon, 2010-12-06 at 10:58 -0800, Brian Paul wrote: > I'd like to simply try --cppflags for now and see if that fixes the > problem for us. There's a few -D flags that we also need; it's not > just the -I path. I agree. The scons build has been using --cppflags since the very beginning. I d

Re: [Mesa-dev] LLVM_CFLAGS

2010-12-06 Thread Brian Paul
I'd like to simply try --cppflags for now and see if that fixes the problem for us. There's a few -D flags that we also need; it's not just the -I path. -Brian On 12/06/2010 11:27 AM, Bob Gleitsmann wrote: There is an option --includefiles that returns the directory with the include files. I

Re: [Mesa-dev] LLVM_CFLAGS

2010-12-06 Thread Corbin Simpson
Isn't there a --cflags-only-I or something along those lines? Sending from a mobile, pardon the brevity. ~ C. On Dec 6, 2010 9:42 AM, "Dan Nicholson" wrote: > On Mon, Dec 6, 2010 at 9:15 AM, Brian Paul wrote: >> On 12/05/2010 02:06 AM, Bob Gleitsmann wrote: >>> >>> Hello, >>> >>> Can someone ex

Re: [Mesa-dev] LLVM_CFLAGS

2010-12-06 Thread Dan Nicholson
On Mon, Dec 6, 2010 at 9:15 AM, Brian Paul wrote: > On 12/05/2010 02:06 AM, Bob Gleitsmann wrote: >> >> Hello, >> >> Can someone explain the value of including this in >> mesa/src/gallium/Makefile.template: >> >> ifeq ($(MESA_LLVM),1) >> LIBRARY_DEFINES += $(LLVM_CFLAGS) >> endif >> >> ? >> This e

Re: [Mesa-dev] LLVM_CFLAGS

2010-12-06 Thread Brian Paul
On 12/05/2010 02:06 AM, Bob Gleitsmann wrote: Hello, Can someone explain the value of including this in mesa/src/gallium/Makefile.template: ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif ? This effectively adds the LLVM cflags to gcc compiles if LLVM is enabled. One side-effect

[Mesa-dev] [Bug 32093] [swrast] implementation error: _mesa_clip_tab[4] failed test (x86)

2010-12-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=32093 Brian Paul changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

Re: [Mesa-dev] [PATCH] Export TLS support in gl.pc

2010-12-06 Thread Julien Cristau
On Sun, Dec 5, 2010 at 20:47:01 -0800, Eric Anholt wrote: > What is this patch for? According to the second mail quoted, a TLS > loader works for both TLS and non-TLS drivers -- that is to say, the X > Server's loader should always default to having TLS support, regardless > of whether the (prob