On Mon, 19 Nov 2012 18:41:10 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Mon, 19 Nov 2012 10:05:19 +0100 Martin Jansa > <martin.ja...@gmail.com> 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 > > > <martin.ja...@gmail.com> 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 > > > > > <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). > > > > > > 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 How does evas_generic_loaders fit into that? > 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. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP 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
