[Mesa-dev] RFC: Prune stale components
Jose Fonseca
jfonseca at vmware.com
Wed Mar 4 00:31:35 PST 2015
On 04/03/15 00:24, Emil Velikov wrote:
> On 03/03/15 22:04, Jose Fonseca wrote:
>> On 03/03/15 18:39, Emil Velikov wrote:
>>> On 3 March 2015 at 17:16, Jose Fonseca <jfonseca at vmware.com> wrote:
>>> ...
>>>>
>>>> I've prototyped this in
>>>>
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_-7Ejrfonseca_mesa_log_-3Fh-3Dremove-2Dst-2Degl&d=AwIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=DBmTkQmzY89vDw_KLOol0FBhKxmBTyqNfsx_ly5H-ZU&s=zhIQc271rsRkCQHGsaFYKm3SFwRTGWAib63t3Fjdhyo&e=
>>>>
>>>>
>>>> The changes are massive, so I'm not sure it's even worth spamming the
>>>> list
>>>> with them.
>>>>
>>>> Could you please give a look and let me know if there are any concerns?
>>>>
>>> I've spotted a few trivial bits:
>>>
>>> - windows/gdi: Remove.
>>> Drop drivers/windows from src/mesa/Makefile.am:EXTRA_DIST
>>> The driver had interesting api/wrapper similar to osmesa. Did not know
>>> that :-)
>>>
>>> - st/egl: Remove.
>>> Update the src/egl/main/Sconscript to create a SharedLibrary, add
>>> versioning, create symlink - copy the bits from egl-static.
>>
>>> Drop st/egl and targets/egl-static from
>>> src/gallium/Makefile.am:EXTRA_DIST
>>
>>> Remove the _EGL_BUILT_IN_DRIVER_GALLIUM define from
>>> src/egl/main/Android.mk.
>>> - st/vega: Remove.
>>> A few "openvg" references left - one in configure.ac another one in
>>> docs/contents.html
>>
>> Thanks. I pushed a new version of the branch with all issues fixed.
>>
> I'm guessing you made a typo in src/egl/main/SConscript
>
> +egl = env.InstallSharedLibrary(egl, version=(1, 0, 0))
>
> Shouldn't the version be 1.4 ?
No, it wasn't a typo. It matches what autotools does now.
I can't say which is more correct 1.0 or 1.4, but it doesn't make sense
for SCons to do something different than autotools for the exact same code.
>
>>
>>>
>>>> The only snafu is Android.mk -- it will be broken with gallium
>>>> drivers until
>>>> somebody familiar with that infrastructure updates it to use
>>>> egl_dri2. But
>>>> it should build fine without gallium drivers.
>>>>
>>> The Android build is mostly limping around mesa 10.4. I've pinged the
>>> Android-x86 guys, but but might get to it soon(ish). Don't worry too
>>> much about it.
>>>
>>> I'm guessing that the scons and automake build do not point out
>>> anything unusual ?
>>
>> Right. automake, scons/linux and scons/windows all build happily. Of
>> course, automake has many options, and I only tested one (with dri and
>> gallium sw rasterizers).
>>
> These components are rather nicely isolated, so it should not matter
> that much.
>
> I'm suspecting that scons does not link against all libs for libEGL.
ldd -r build/linux-x86_64-debug/egl/main/libEGL.so is clean.
> Adding -Wl,--no-undefined/-Wl,-z,defs to SHLINKFLAGS should clear it up,
> yet feel free to do it as a follow up. I would highly recommend adding
> it (-Wl...) for every SharedLibrary in scons. Using the version scripts
> like autotools, to restrict the exported symbols, will be great.
I'll see what can be done.
Unfortunately (at least in the past) we used to have .so depending on
symbols from the .so/executable that dlopened it (ie, cyclic
dependencies), so doing this universally woulddn't be possible. Not sure
if that's still the case.
> With the versioning question addressed, feel free to add
> Reviewed-by: Emil Velikov <emil.l.velikov at gmail.com>
Thanks for the reviews.
> Please drop a couple of lines in the release notes, when you're finished
> removing all the old/unused bits.
Sure.
> -Emil
>
> P.S. Strange. After spending so much time fixing the builds, it feels so
> nice as various chunks of it end up removed :-P
Yeah. I feel the same, even with code I wrote myself. Maintaining code
takes a toll in time and energy (all those worries about things one
should have done but never had the time). So removing code (or
abandoning projects) is effectively taking a weight from ones
conscience. And enables one to use that time/energy for better things.
More information about the mesa-dev
mailing list