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.). > Cheers, > > > in the end - we can argue here if it is technically possible via doing > > multiple builds and packagings or not, but as long as this is needed we > > will piss off and push away packagers and distros if we pus them to use > > esvg. so effectively the only solution is that esvg be a funky "hacker > > only" thing never to be realistically used UNLESS it becomes part of the > > efl tree build OR that it is possible to build the esvg loader outside of > > the efl tree at a stage AFTER efl is build and installed. > > > > -- > > ------------- 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 > > -- > Martin 'JaMa' Jansa jabber: [email protected] -- ------------- 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
