[Intel-gfx] [PATCH i-g-t 2/2] Revert "lib/igt_aux: Make procps optional"

Daniel Vetter daniel at ffwll.ch
Wed Nov 29 15:51:03 UTC 2017


On Wed, Nov 29, 2017 at 03:24:41PM +0200, Arkadiusz Hiler wrote:
> On Wed, Nov 29, 2017 at 12:07:06PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 24, 2017 at 05:17:48PM +0200, Arkadiusz Hiler wrote:
> > > This reverts commit d7d3f4e87b827152f00bdf89a67871736672b492
> > > and gets rid of the config option from the meson.build.
> > > 
> > > It was needed only for the Android support.
> > > 
> > > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > 
> > Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> > 
> > on both patches.
> > 
> > I think there's a bunch more things that are only optional because of
> > Android. Stuff like udev and glib iirc. But maybe we want to keep those,
> > to avoid to much pain for the next time around someone wants to implement
> > Android support natively.
> > -Daniel
> 
> Pushed, thanks for Acks and R-bs!
> 
> As of further cleanups, there is one really impending on us
> - the libunwind one.
> 
> We have huge sections of the code wrapped in ifdefs which bit us more
> than once - it's easy to misplace code in there, code that should always
> be compiled.
> 
> This needs a rework, initial ideas is to put all the unwind related mess
> into separate file and compile the whole thing conditionally - for
> clearer separation.
> 
> We would also need "fallback" noop implementation of some of those
> functions.
> 
> Or we may ask ourself, with Android support gone, is this really worth
> it and shouldn't we make libunwind non-optional and just get rid of the
> preprocessor macors? :-)

+1 on simply requiring libunwind. The other option is more work, and can
be done when we have a real ask for it (aka Android, in which case your
suggested split-out is probably what we want).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list