On Mon, 19 Nov 2012 10:05:19 +0100 Martin Jansa <[email protected]> said:
> 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. i know - pure cross-compile needs them staged in the native format to be able to be run first. so you need a 2 stage compile process for efl regardless. > 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. but useless for others because you are already doing a bootstrap because you have a cross-dev setup. they are not. you basically force a multi-stage package build process on EVERYONE to be figured out themselvesas to hoe to do it. this is just not acceptable. ignore the esvg case - the nasty one is edje_cc, and we can solve that internally by doing stages within the build - much like gcc does. esvg, as long as it remains out of tree is an "unsolvable" as it stands. > Or we can "bundle" esvg in efl recipe and build it "in-tree" between > eina and evas. my choices were: 1. esvg and everything it needs come into the efl tree. 2. we are able to build loaders out-of-tree and have them work 3. the esvg svg loader is useless for most and beyond a developer toy may as well not exist. unless we make changes beyond just building an efl tree, #3 is what will happen. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
