On Wednesday, November 7, 2012, Martin Jansa wrote: > On Wed, Nov 07, 2012 at 05:38:03PM +0100, Gustavo Sverzut Barbieri wrote: > > Some updates based on talks here, Vincent would you look at doing them? > > > > On Mon, Nov 5, 2012 at 11:51 AM, Gustavo Sverzut Barbieri < > > barbi...@profusion.mobi <javascript:;>> wrote: > > > > > Hi all, particularly Vincent and Raster (notes to Etrunko/Devilhorns): > > > > > > Since EFL got the evas merge, I'd like to have evas options reduced as > > > it's still too much. My suggestion is: > > > > > > - pixman: should be a single option. But do we need it at all? > > > > > > > remove and later implement the NEON functions from Pixman in Evas. > > > > > > > > > > > - tile-rotate: can't we always have it enabled? > > > > > > > no comments so far. > > > > > > > > > - sse3: we shouldn't have this, as it could be detected at compile > time. > > > also be able to disable at runtime. > > > > > > > always enable if x86 && compiler supports, as well as others (mmx, sse, > > ...). Will detect if usable at runtime. > > What about cross compilation on x86?
You can detect based on target arch + test to see if compiler can work with the instruction set. > > > > - static-software-generic: always on > > > - buffer engine: always enabled and static > > > - xcb x xlib: --with-x11=xcb, xlib or none. > > > - gl, gl-es...: --with-gl=gl, gles or none. > > > - direct3d, ddraw, gdi: remove option, enabled if platform supports it > > > (windows). > > > - directfb: remove and also code. > > > - cocoa: remove option, enabled if platform supports it (mac). > > > - ps1light: remove option, enabled if platform supports it. > > > - fb (framebuffer): always enabled if platform supports it (linux). > > > - wayland: turn into --enable-wayland. It will turn on egl if > > > --with-gl=egl? Etrunko? Devilhorns? > > > - dither mask: I'd say remove this from configuration, or turn into a > > > single --with-dither-mask=full, small, line or none. > > > > > > > mixed bag, some say it can be kept as a --with-dither-mask, I'd remove > and > > leave the #ifdef in the code. Embedded guys can always specify the > -DBLABLA > > to save some kilobytes. > > > > > > > > As or harfbuzz/fribidi I'd like to always enable them... I know some > > > distros don't package, but given that Glib share many authors of those > > > libraries and they do include a copy, and evas already includes > > > linebreak... we better include our supported version. Alternatively we > > > require and people that package us, will package those. Worse scenario: > > > --enable-complex-languages. > > > > > > > As per Tasn, fribidi is always there. Harfbuzz is almost never there but > > seems next Pango will change and instead of copy/provide one, will link > to > > system. Still to be decided what to do with Harfbuzz, but likely: > > > > - fribidi: always enable > > - harfbuzz: provide a copy (as we do with liblinebreak). > > > > Also, I forgot about fontconfig: always enable. > > > > > > > > simple-x11: what is that? can we merge it into new --with-x11? > > > > > > > > remove, nobody knows if that hack is still needed by OpenEmbedded. likely > > not. > > It's still used in OE, but especially evas does not use that in source > AFAIK: > > OE @ ~/projects/e $ git grep want_evas_simple_x11 > e/configure.ac: [ want_evas_simple_x11=$enableval ] > e/configure.ac:dnl if test "x$want_evas_simple_x11" = "xyes"; then > ecore/configure.ac:want_evas_simple_x11="no" > ecore/configure.ac: [want_evas_simple_x11=$enableval]) > ecore/configure.ac: if test "x$want_evas_simple_x11" = "xyes"; then > evas/configure.ac: want_evas_simple_x11="yes" > evas/configure.ac: want_evas_simple_x11="no" > expedite/configure.ac: [want_evas_simple_x11=$enableval] > expedite/configure.ac: if test "x$want_evas_simple_x11" = "xyes"; then > > And if it finds headers in correct sysroot then it's not needed in ecore > too. > > So remove? OE should provide PC files and let everybody be happy > Cheers, > > > > > > > > > > > > > gif, svg, tiff and webp: what to do? most systems includes libgif and > > > libtiff, many includes webp these days but not so common. Nobody will > > > include our esvg requirement. What to do? > > > > > > > > I like vincent idea --with-image-loaders, but I'd always enable gif and > > tiff, leave webp and svg to be chosen. > > > > > > > > Last but not least: vincent, all the fb/x11/gl/wayland will also be > shared > > with ecore, then it would make sense to move those to a common section > and > > remove the evas prefix. > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: barbi...@gmail.com <javascript:;> > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > ------------------------------------------------------------------------------ > > LogMeIn Central: Instant, anywhere, Remote PC access and management. > > Stay in control, update software, and manage PCs from one command center > > Diagnose problems and improve visibility into emerging IT issues > > Automate, monitor and manage. Do more in less time with Central > > http://p.sf.net/sfu/logmein12331_d2d > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net <javascript:;> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com <javascript:;> > -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
