On Wed, Dec 5, 2012 at 12:43 PM, Vincent Torri <[email protected]> wrote: > On Wed, Dec 5, 2012 at 2:14 PM, Flávio Ceolin > <[email protected]> wrote: >> On Wed, Dec 5, 2012 at 12:41 AM, David Seikel <[email protected]> wrote: >>> On Tue, 4 Dec 2012 23:44:48 -0200 Gustavo Sverzut Barbieri >>> <[email protected]> wrote: >>> >>>> On Tuesday, December 4, 2012, David Seikel wrote: >>>> >>>> > On Tue, 4 Dec 2012 12:24:28 -0200 Flávio Ceolin >>>> > <[email protected] <javascript:;>> wrote: >>>> > >>>> > > I have recently committed in IN-EFL/ecore some patches >>>> > > implementing support for loadables modules. It makes the engines >>>> > > been loaded when they are needed. I did not break the api, so >>>> > > each engine still has its own api. It's far from ideal, should >>>> > > exists one api used by all the modules but at least until the >>>> > > next version, we need keep the api. >>>> > > >>>> > > The modules (engines) usually exports just on symbol, the "new" >>>> > > function, the other necessary functions are in the engine's >>>> > > interface. >>>> > >>>> > I'm a bit confused here, why is this needed? Isn't it the case that >>>> > more often than not there's only one useful engine that is >>>> > supported by the hardware? And not like you will be moving a >>>> > window on the fly from X11 to fb? Certainly I don't think anyone >>>> > will be using X11 and Windows engines in the same run of their >>>> > proggy. How is this supposed to work? What use case is there for >>>> > it? >>>> > >>>> > I can understand if it was for image loaders & savers, and other >>>> > stuff, that makes sense, but engines? >>>> >>>> >>>> Before linking to ecore_evas built with x11, wayland and directfb >>>> would bring all those libs even if just buffer engine is used. Also >>>> if you built with them, you could not remove x11 or wayland >>>> afterwards. >>>> >>>> With the new infra, ecore_evas behaves just like Evas and each engine >>>> is a separate shared object, will just bring deps as its loaded. Can >>>> be removed from the system without breaking dynamic linkage. >>> >>> Ah that makes sense. The way it was described sounded more like "one >>> app can load and unload various engines at run time on the fly" to me, >>> which just sounded odd. >> >> The main reason to support it, it is what raster said, add and remove >> support for engines without need rebuild the libecore_evas. It's also >> pretty good for the packagers because they don't need build with many >> engines enabled by default increasing the number of dependencies. > > which is a cotradiction with the merge as the merge requests some > dependencies, now :)
actually this was not well placed by flavio. General distro packagers can now COMPILE efl with every module enabled (sdl, x11, fb...), yet they PACKAGE libecore_evas.so with only basic dependencies (libecore.so, libevas.so) and not dependent on xlib/xcb or sdl. These would be dependencies of ecore-evas-module-x11 and ecore-evas-module-sdl. Something like: libecore-evas.pkg: depends on libecore.pkg and libevas.pkg (eo, eina... as well) ecore-evas-module-x11.pkg: depends on libecore-evas.pkg and xlib (or xcb) ecore-evas-module-sdl.pkg: depends on libecore-evas.pkg and sdl e17.pkg: depends on libecore-evas.pkg and ecore-evas-module-x11.pkg then ecore-evas-module-sdl.pkg is not installed or required. But one user may install that so his app will work with sdl as well. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
