[Mesa-dev] Merging gallium-rect-textures and debug-refcnt?

[Keith Whitwell]

On Fri, 2010-08-20 at 04:11 -0700, Luca Barbieri wrote:
> > Hasn't this already happened somewhere - util/u_snprintf.c ?
> Indeed, I'll fix it to use those.
> 
> There's something (independent from this) that bugs me though.
> 
> Why does Gallium feel the need to implement all this stuff with ad-hoc
> names, instead of, for instance, just implementing a function called
> "sprintf" if the platform doesn't provide it?
> Other similar instances are the "INLINE" macro instead of an "inline",
> "MALLOC" instead of "malloc", PIPE_ARCH_X86 instead of "__i386__", and
> surely many others.
> On the same note, if, for instance, "stdio.h" doesn't exist, one can
> just write an header called "stdio.h" and add that directory to the
> include path on the affected platform, instead of inventing another
> header name.

I guess the issue would be if there was something with that name already
but which wasn't workable for some reason.  Windows provides busted and
incomplete implementations of some of these functions, for instance.

> The result of this is that the codebase is cluttered with non-standard
> (and often ugly) conventions, and it is trivial to write code that
> works perfectly on Linux, but not on other platforms, because it uses
> the standard naming instead of the strange Gallium-specific names (as
> you can see in the case of this patchset).
> 
> As a byproduct of this, hardware drivers tend to drift away for this
> unusual convention, since they are never built for Windows. For
> instance, nouveau drivers use "inline" instead of the "INLINE" that
> Gallium code is supposed to use.

Gallium followed core mesa for this, and that convention is still in
core mesa, eg:

static INLINE void
_mesa_init_accum_dispatch(struct _glapi_table *disp)
{
}

I'd be ok to see this become "inline", I don't see any obvious problems
that can't be worked around.  Brian's on holidays atm, but when he's
back it would make sense to have his input on this as well.

> Given that I suspect that essentially no one outside VMware does Mesa
> development on a non-Unix platform, it seems a good idea to make sure
> that such code also works on Windows automatically without needing to
> be fixed each time.

I'm sure we're not the only ones.  But yes, if we can say in general
that there's a way to reduce the textual discrepancies without impacting
the ability to build and run on other platforms, then great.

Let's take it step by step though.

> Would a set of regular expressions plus simple patches that tries to
> fix all instances of this all over the codebase be positively
> accepted?
> I seem to recall that a similar substitution was applied to the
> non-Gallium parts of the Mesa.

I think there has been some movement there, but things like INLINE, etc.
still exist in core Mesa.

Keith