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) ? Vincent ------------------------------------------------------------------------------ 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
