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

[José Fonseca]

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.
> 
> 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.
> 
> 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.
> 
> 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.

It's not ad-hoc names. They have prefixes. And it's a standard practice.
Although you typically see a single prefix for the whole project whereas
we have per module prefixes.

The advantage of having a prefix is that it makes it easy to detect when
people don't include the proper headers such as u_string.h, and it
guarantees one can wrap around even buggy OS implementations without
doing #define magic. It also allows to easily add wrapping.

But that said, I don't feel very strongly about this anymore. Getting
tired of saying the same thing over and over.

Jose