On Mon, Nov 19, 2012 at 04:26:30PM +0900, Carsten Haitzler wrote: > On Mon, 19 Nov 2012 06:28:45 +0100 Vincent Torri <vincent.to...@gmail.com> > said: > > > On Mon, Nov 19, 2012 at 2:06 AM, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > On Sun, 18 Nov 2012 17:25:13 +0100 Vincent Torri <vincent.to...@gmail.com> > > > said: > > > > > >> On Sun, Nov 18, 2012 at 5:16 PM, Andreas Volz <li...@brachttal.net> > > >> wrote: > > >> > Am Sat, 17 Nov 2012 18:23:02 +0100 schrieb Vincent Torri: > > >> > > > >> >> On Sat, Nov 17, 2012 at 5:42 PM, Andreas Volz <li...@brachttal.net> > > >> >> wrote: > > >> >> > Am Sat, 17 Nov 2012 11:21:58 +0000 schrieb gpl4all: > > >> >> > > > >> >> > Interesting! > > >> >> > > > >> >> > Does enesim stand in some sort of competition compared to part of > > >> >> > EFL? Or do they have another mission? > > >> >> > > >> >> it's a vector-based rendering library, which could be in competition > > >> >> more with cairo than with evas. But Enesim could be used as rendering > > >> >> engine for evas, for example. > > >> >> > > >> >> To be more accurate, Enesim is the name of the project. Its stack is > > >> >> composed of several libraries > > >> >> Enesim > > >> >> Emage > > >> >> Etex > > >> >> Etch > > >> >> Ender > > >> >> Egueb > > >> >> etc.... > > >> >> > > >> >> See the wiki in the website for mor einformations. > > >> > > > >> > It seems to use at least Eina as base. And then Evas uses it again. > > >> > Funny... > > >> > > > >> > As Eina is now in Efl source together with Evas it's a funny > > >> > cyclic dependency. :-P > > >> > > >> yes. So we can do a bootstrap first. Anyway, I think that this > > >> bootstrap will be needed for edje, iirc > > > > > > thats very different. with edje we can make the bootstrap happen as part > > > of > > > the efl build, BUT we can't with esvg because it's external. > > > > we can just build eina, then esvg, then the whole stack > > we can't because we dont control the build of esvg. it's not part of the build > tree. > > what the issue here is, is that packagers what to do this: > > configure XXXXXX > make > make install > package results > > the do not want to (and will avoid like the plague): > > configure XXXX (eina only) > make > make install > package pkg1 > > <compile + package depenedncy> > > configure XXXXXX > make > make install > package results > > cross-compile systems aside (and scratchbox fixes the native tools vs target > tools thing), packagers will complain, moan and avoid efl and e if we make > them > have to package it TWICE - yes. they will insist on having to package it twice > because their build systems install dependencies based on package build > depends. that means they have to create and initial eina package just to be > able > to build esvg, then just to re-build efl and somehow disable the eina build > then (to ensure the same eina is used from before) OR.. to replace the > previous > eina which now rsvg was built against.. which they will not like either etc.
As meta-efl (layer for OpenEmbedded) maintainer, I fully agree with this. And it would be much better to disable eina build when building the rest, because we cannot replace eina in sysroot (it needs only one "owner" of files staged by build). Cheers, > in the end - we can argue here if it is technically possible via doing > multiple > builds and packagings or not, but as long as this is needed we will piss off > and push away packagers and distros if we pus them to use esvg. so effectively > the only solution is that esvg be a funky "hacker only" thing never to be > realistically used UNLESS it becomes part of the efl tree build OR that it is > possible to build the esvg loader outside of the efl tree at a stage AFTER efl > is build and installed. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel