On Mon, Nov 19, 2012 at 05:48:35PM +0900, Carsten Haitzler wrote: > On Mon, 19 Nov 2012 08:41:15 +0100 Martin Jansa <[email protected]> said: > > > On Mon, Nov 19, 2012 at 04:26:30PM +0900, Carsten Haitzler wrote: > > > On Mon, 19 Nov 2012 06:28:45 +0100 Vincent Torri <[email protected]> > > > said: > > > > > > > On Mon, Nov 19, 2012 at 2:06 AM, Carsten Haitzler <[email protected]> > > > > wrote: > > > > > On Sun, 18 Nov 2012 17:25:13 +0100 Vincent Torri > > > > > <[email protected]> said: > > > > > > > > > >> On Sun, Nov 18, 2012 at 5:16 PM, Andreas Volz <[email protected]> > > > > >> wrote: > > > > >> > Am Sat, 17 Nov 2012 18:23:02 +0100 schrieb Vincent Torri: > > > > >> > > > > > >> >> On Sat, Nov 17, 2012 at 5:42 PM, Andreas Volz > > > > >> >> <[email protected]> > > > > >> >> 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). > > well once the efl tree gets to the point of needing to compile elementary, > then > we need to make it have its own bootstrap phase - compile, but install into > some > tmpdir in the build dir and run the edje_cc & use the all the libs from there > (set PATH, LD_LIBRARY_PATH etc.). yes - i know this doesn't work in pure > cross-compile. for a pure cross-compile you'd need to disable the bootstrap > via > some option (yet to be done) and provide tools like edje_cc and eet in the > cross-dev sysroot. then you have to provide much more than eina - u need eina, > ecore, embryo, eet, edje... for starters. :) (though as OE does now - it's a > minimal build that doesnt need x11 etc.).
Yes, but those are native deps, which are staged in separate sysroot, easy to define and target recipe then needs just path to correct edje_cc in that sysroot etc. But for esvg if I understood it correctly you need target eina. So we would have to add eina-initial recipe which builds only eina from efl tree in 1st step and stage it in some eina-initial prefix, then build esvg (and hack configure to use eina only from eina-initial prefix) and then build complete efl. Or we can "bundle" esvg in efl recipe and build it "in-tree" between eina and evas. Cheers, -- Martin 'JaMa' Jansa jabber: [email protected]
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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
