On Mon, 19 Nov 2012 10:08:16 +0100 Vincent Torri <[email protected]> said:
> On Mon, Nov 19, 2012 at 10:05 AM, Martin Jansa <[email protected]> wrote: > > 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. > > can't we do some kind of copy of an external repo (which would be > updated for each svn up) ? and this external esvg repo will need about 4 or 5 different esvg/enesim/ender etc. things which each separately have to have their libraries ./configured etc. and they will, in their current form, simply not find eina and fail. they will need merging to assume the eina in-tree and link to it like the other bits of efl. that means basically forking all of enesim and friends as the changed trees will need to be integrated. that's one of the options - but without co-operation from turran this is going to be the most painful option. -- ------------- 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
