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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
