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

[José Fonseca]

On Fri, 2010-08-20 at 06:17 -0700, Luca Barbieri wrote:
> > And define magic is very brittle. Especially with C++: you #define
> > printf to be something else, but nothing prevents a class or a namespace
> > to have the printf symbol in its scope.
> 
> Yes, but hopefully that's going to be very rare.
> 
> Alternatively, you can do this:
> 1. Compile with cl /Dsprintf=dontuse_windows_sprintf
> 
> 2. Put in a header:
> #include <windows.h>
> #undef sprintf
> 
> static __forceinline sprintf(...)
> {
>  my_vsprintf(...)
> }
> 
> 3. Put in a C file:
> void my_vsprintf()
> {...}
> 
> If the header is not included, linking will fail (due to the reference
> to dontuse_windows_sprintf), otherwise the custom version will be used
> whenever sprintf is called, while still having sprintf as a (forced
> inline) function.
> 
> It's also possible to ask the compiler to include the header with a
> command line switch (-include in gcc), so that fully standard code
> will work.
> 
> As a third option, you can have a build step that creates a patched
> copy of the Windows headers, kind of like GCC's fixincludes.
> 
> > And again, using the CRT for strings is subject to the
> > current locale. Care has to be taken when using it for stuff other that
> > debug printing (e.g., shader parsing, which was exactly the bug what
> > happened before in Mesa).
> 
> Only some functions respect the locale.
> 
> The glibc documentation says this:
>      `strcmp' does not take sorting conventions of the language the
>      strings are written in into account.  To get that one has to use
>      `strcoll'.
> 
> And MSDN says this:
> In locales for which the character set and the lexicographic character
> order differ, use strcoll rather than strcmp for lexicographic
> comparison of strings according to the LC_COLLATE category setting of
> the current locale. Thus, to perform a lexicographic comparison of the
> locale in the above example, use strcoll rather than strcmp.
> Alternatively, you can use strxfrm on the original strings, then use
> strcmp on the resulting strings
> 
> > Another example are math.h's sinf/cosf etc. It's indeed quite convenient
> > to have the standard names. But some CRTs use #defines other inlines,
> > and then suddenly different versions of the compiler/CRT do different
> > things.
> 
> Isn't that going to be equivalent if the macros use the argument only once?
> 
> > I still have the plan to make a CGRT [1] module to centralize all
> > existing OS portibility and abstract data types used everywhere in the
> > mesa tree.
> 
> How about just making everything in the Mesa tree depend
> unconditionally on Gallium, and let them use auxiliary/, os/, etc.
> directly?

No. Some people would have an indigestion, and it Gallium itself would
benefit from the cleanup of seperating OS/debug/ADT stuff from the
gallium speific utilities. ATM everything is a big spaghetti inside
auxiliary/* 

> In addition to all the duplicated portability code, there are some
> other things like util_format that Mesa would benefit from using,
> instead of having its own inferior version.

Yes. That would be a good follower.

> It would also be great if Mesa IR and TGSI were unified, since their
> minor differences don't seem to warrant having two IRs.4444

Perhaps. Anyway, one thing at a time.

Jose