[Mesa-dev] [PATCH 2/2] mesa/glsl: rename preprocess to glcpp_preprocess

[Kenneth Graunke]

On 09/13/2012 11:44 PM, Dave Airlie wrote:
> On Fri, Sep 14, 2012 at 4:36 PM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>> On 09/13/2012 05:13 PM, Dave Airlie wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> This symbol with dricore escapes into the namespace, its too generic,
>>> we should prefix it with something just to be nice.
>>>
>>> Should be applied to stable + 9.0
>>>
>>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>>
>> Forgive me for not understanding how linkers work, but...this symbol
>> should -not- be exposed at all.  It's completely internal and nobody
>> except the current callers should ever call it.  If it's getting exposed
>> that's broken and we need to fix that.  I hate to think what else is
>> getting exposed.
>>
>> As I understand it, all of our visibility flags stopped taking effect at
>> some point during the automake conversion.  We need to figure out why
>> and how to fix it...IMHO we can't release without fixing that.
>>
>> Is it not possible?
> 
> Not with libdricore, since we have no defined API between it and the drivers.

Yeah...I suppose short of defining such an API, there's nothing that
really can be done.  Somehow I thought it worked better in the 8.0 days,
but maybe that was only with --disable-shared-dricore.

> If we want visibility to work we need to either drop libdricore, or
> start to markup the visible APIs between it and the drivers. ajax
> suggested a crazy script to build it all, get the list of apis needed
> by the drivers, rebuild with those exposed. I'm not sure how feasible
> that is.

That could work.  Might even be the best approach.  But yeah, does sound
a bit crazy...

Honestly, I've never been a fan of dricore.  As I understand it, the
whole point of it was to save disk space on distro install media.  That
really feels like the tail wagging the dog.  Yes, saving space is
useful, but not if it causes a lot of pain.

When we were using rpath, we kept hitting issues where we'd get the
wrong dricore paired with the libGL and drivers we were using, leading
to terribly bizarre crashes and failures.  I remember constantly having
to sanity check every bug report I got from QA to make sure that their
issues weren't caused by a random bad build or install.

Now that it's installed as a normal library, I haven't seen as many
problems, but I still doubt the approach.  I suppose we're rather unique
in that we have a bunch of drivers which share a large body of code, and
don't want to define an API, but...I don't see any other project doing
anything like this.

I wonder if there's something better we can do.  I don't know what though.

> Since neither of these seem like a simple plan, I'd at least try to
> limit the damage in the 9.0 timeframe which is what these two patches
> do. yylex is definite problem preprocess was the most generic one I
> saw after that.
> 
> Dave.

Alright, you've convinced me.  Patch 2 gets my Acked-by.

Thanks Dave.