[Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with

[Jose Fonseca]

On 19/06/15 23:09, Emil Velikov wrote:
> On 19 June 2015 at 21:26, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 19/06/15 20:56, Emil Velikov wrote:
>>>
>>> Hi all,
>>>
>>> A lovely series inspired (more like 'was awaken to send these out') by
>>> Pal Rohár, who was having issues when building xlib-libgl (plus the now
>>> enabled gles*)
>>>
>>> So here, we teach the final two static glapi users about shared-glapi,
>>> plus some related fixes. After this is done we can finally start
>>> transitioning to shared-only glapi, with some more details as mentioned
>>> in one of the patches:
>>>
>>>       XXX: With this one done, we can finally transition with enforcing
>>>       shared-glapi, and
>>>
>>>        - link the dri modules against libglapi.so, add --no-undefined to
>>>       the LDFLAGS
>>>        - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds
>>>       in the loaders - libGL, libEGL and libgbm.
>>>        - start killing off/cleaning up the dispatch ?
>>>
>>>       The caveats:
>>>       1) up to what stage do we care about static libraries
>>>        - libgl (either dri or xlib based)
>>>        - osmesa
>>>        - libEGL
>>>
>>>       2) how about other platforms (scons) ?
>>>        - currently the scons uses static glapi,
>>>        - would we need the dlopen(...) on windows ?
>>>
>>> Hope everyone is excited about this one as I am :-)
>>
>>
>> Maybe I missed the context of this changes, but why this matters or is an
>> improvement?
>>
> If one goes the extra mile (which this series doesn't) - one configure
> option less, substantial some code de-duplication and consistent use
> of the code amongst all components provided. This way any
> improvements/cleanups made to the shared glapi will be available to
> osmesa/xlib-libgl.

I'm perfectly happy with removing the configure option.

And I understand the benefits of unified code paths, but I believe that 
for this particular case, the difference in requirements really demands 
the separate code paths.

>> In summary, having the ability of using a shared glapi sounds great, but
>> forcing shared glapi everywhere, sounds a bad idea.
>>
> I'm suspecting that people might be keen on the following idea - use
> static glapi for osmesa/xlib-libgl and shared one everywhere else?

Yes, that sounds reasonable for me.  (Needs libgl-gdi too.)

>
> I fear that this will lead to further separation/bit-rot between the
> different implementations, but it seems like the bester compromise.

I don't feel strongly between: a) using the same source code for both 
static/shared glapi (switched by a pre-processor define), or b) only 
share the interface but have shared/static glapi implementations.  I'm 
actually not that familiar with that code.


Either way, we can have two glapi build targets (a shared-glapi and a 
static-glapipe) side-by-side, so that there are no more source-wide 
configure flags.


I believe a lot of the complexity of that code comes from assembly.  I 
wonder if it's really justified nowadays (and even if it is, whether it 
would be better served with GNU C assembly.) Futhermore, I believe on 
Windows we use any assembly, so if we split shared/static glapi source 
code, we could probably abandon assembly from the static-glapi.


Jose