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

[Jose Fonseca]

On 04/02/15 20:18, Kenneth Graunke 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.
>
> 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 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...
>
> 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?

We had src/util in the include path. But now we don't, so yes, header 
collision is less likely.

There's a problem with the symbols though -- gallium can (and is) 
embedded in other software systems -- it's not just used to make OpenGL 
drivers.

And if src/util is to be a dependency of gallium, it means it ends up 
being statically linked against other stuff too.   And if everybody just 
uses the most obvious header names, and the most obvious symbol names, 
it's just a matter of time until a collision happens.

That said, it looks the symbols so far in u_mesa

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

To be clear: I'm all for moving as much code from src/gallium/auxility 
to src/util -- that's my objective here.

But I believe that not all code in src/gallium/auxiliary/util can be 
moved into src/util as some is gallium specific (depends on gallium 
types, helpers, etc), so merely moving files won't work generally: the 
gallium-specific stuff needs to stay behind, and therefore, most 
co-exisit without colliding with the stuff that gets moved into src/util.

Even u_math.[ch] can't be trivially moved -- it depends on u_debug.[ch] 
which has a bunch of gallium specific stuff.

Moving all this is one go will be tricky.  Doing piece by piece seems 
safer and more guaranteed.


I don't feel strongly about this.  But it's a matter of practicality: I 
can't afford take a week off my main work to move the bulk of 
src/gallium/auxiliary/util into src/util, but I can take a couple of 
hours to get a sub-module, or a subset of it.

Maybe I can approach it from the different angle: if I get things that 
are dependend by pretty much everything else in 
src/gallium/auxiliary/util, like p_config.h and u_debug.h, out of the 
way, then the rest will be easier to migrate...




Jose