[Mesa-dev] Rename mesa/src/util (Was: gallium/util: add u_bit_scan64)

[Emil Velikov]

Hi all,

Fwiw, I'm 100% behind Jose's arguments, let me try and justify why:

On 4 February 2015 at 20:18, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On Wednesday, February 04, 2015 02:04:38 PM Jose Fonseca wrote:
>> This change broke MinGW/MSVC builds because ffsll is not available there.
>>
>>
>> There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch].  So
>> rather than duplicating it in src/gallium/auxiliary/util/u_math.h I'd
>> prefer move it to src/util.
>>
>>
>> And here lies the problem: what header name should be used for math helpers?
>>
>>
>> I think the filenames in src/util and the directory itself is poorly
>> named for something that is meant to be included by some many other
>> components:
>> - there is no unique prefix in most headers
>> - util/ clashes with src/gallium/auxiliary/util/
>>
>>
>> Hence I'd like to propose to:
>>
>> - rename src/util to something unique (e.g, cgrt, for Common Graphics
>> RunTime
>>
>> And maybe:
>>
>> - prefix all header/source files in there with a cgrt_* unique prefix too
>>
>> And maybe in the future
>>
>> - use cgrt_* prefix for symbols too.
>>
>>
>> Jose
>
> "util" is meant to be for shared utility across the entire code base -
> both Mesa and Gallium.  It's been growing slowly as people move things
> there.  It might make sense to move a lot of src/gallium/auxiliary/util
> there, in fact - there's always been a lot of duplication between Mesa
> and Gallium's utility code.  But that's up to the Gallium developers.
>
Imho currently the util library is growing on the basis of "we can
share X let's throw it in there" rather than putting much thought
about the structure/"design" of it - unlike in gallium.

> I think that "util" is precisely the right name.  If a new contributor
> wants to find a hash table, or a set, or some macros...they're going to
> look for utility code.  src/util is obviously named and easy to find.
>
I'm a bit sceptical how many grep-aware people will start looking at
the folder names, rather than grepping the whole project. I'm pretty
such some of you use cscope, yet cannot be certain that you've used it
prior to working on mesa.

> I think any acronym like "cgrt" is going to confuse people.  src/cgrt
> sounds like "some obscure part of the system I can ignore for now" -
> easily overlooked, and what does the acronym mean anyway...
>
You're absolutely correct. Most newcomers will likely ignore the
folder called "cgrt" even if there is handy README inside it.
How about renaming it to "common" or something along those lines - in
gallium there is a convenient separation between util, os, translate,
rtasm, etc some of which can shared with the rest of mesa. It seems to
me that we're picking pieces from all over and trying to shove them in
one place ?

> We chose not to add the "u_" prefix, partly for historical reasons
> (Mesa never used one), but also specifically to avoid clashing with
> src/gallium/auxiliary/util.  Most people don't put src/util in their
> include path, and instead use #include "util/ralloc.h" - which already
> is a prefix of sorts.  What additional value does "u_" provide?
>
The prefix will give us the following:
 - Confidence that no symbols will conflict.
 - Explicit link about the origin of the function.
   - One knows if the function is shared or they can move it.
   - A bit of a "here be dragons" note.

> I think you should just invent a header name and put it there.  "math.h"
> does sound fairly generic.  If you're just reimplementing things like
> ffsll that are usually provided by your system, it might make sense to
> call it something like "os_compat.h" (along the lines of c99_compat.h).
>
I'm all for os_compat.h (or alike), yet I don't see it as a "util".
Thus my idea above about renaming the folder and (optionally) keeping
things a bit more gallium-like.

> Or maybe Brian is right - we could just move Gallium's utility code to
> src/util and use it everywhere.  It'd be nice to not have two sets.
>
If I can speculate - I would assume that bikeshedding is one of the
reasons why things got copied over into gallium. People chose to have
some form of explicit structure and naming scheme, that will be easier
to follow as the project grows and they did not feel like going
through this.

With that said it may be that I'm bikeshedding the most, so I better
shut up now :-)

-Emil