'Re: [E-devel] Re: E CVS: libs/ecore raster'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Re: E CVS: libs/ecore raster
From:       Carsten Haitzler (The Rasterman) <raster () rasterman ! com>
Date:       2006-03-30 23:55:07
Message-ID: 20060331085507.b8212743.raster () rasterman ! com
[Download RAW message or body]

On Thu, 30 Mar 2006 21:20:16 +0200 Falko Schmidt
<kaethorn@stud.uni-stuttgart.de> babbled:

> On Thu, Mar 30, 2006 at 08:13:09AM -0800, Blake B. wrote:
> > 
> > On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote:
> > 
> > >>>
> > >>>ok. i think i might have to poke my finger into it all too - i  
> > >>>notice some
> > >>>totally outrageous "build requirements" (ecore REQUIRES  
> > >>>libdiretfb? no -
> > >>>it's optional and i don't think we should be shipping it as then  
> > >>>the final
> > >>>e install will drag in dfb w2hen actually no apps "use" it - it's  
> > >>>there for
> > >>>special case development). also packages need splitting up into more
> > >>>fine-grained lumps
> > >>>
> > 
> > Definitely.  Evas needs to be done this way too.  I didn't notice the  
> > directfb requirement in there, I build without it.  I think xstasi  
> > must have added it because his repository has support for it (and a  
> > back-ported directfb package)
> > 
> > >>if there're no objections i'll split libecore0 into the following
> > >>packages (which will hopefully fix the dependency issues as well):
> > >>
> > >>libecore0
> > >>libecore0-config
> > >>libecore0-con
> > >>libecore0-dbus
> > >>libecore0-directfb
> > >>libecore0-evas
> > >>libecore0-fb
> > >>libecore0-file
> > >>libecore0-ipc
> > >>libecore0-job
> > >>libecore0-txt
> > >>libecore0-x
> > >>
> > >>are there packages which can be merged into one?
> > >
> > >i like the split this way. it gives fine-grained control. auto- 
> > >dependency
> > >resolving will make sure the right subset is installed.
> > 
> > Cool, will libecore be a virtual package for all of them?  Or  
> > something like libecore-all?
> > 
> good question. as it is now, libecore0 just contains the basic
> infrastructure for the rest:
> 
> [...]
> ./usr/share/ecore
> ./usr/share/ecore/fonts
> ./usr/share/ecore/fonts/fonts.alias
> ./usr/share/ecore/fonts/fonts.dir
> ./usr/share/ecore/fonts/Vera.ttf
> ./usr/share/ecore/fonts/VeraBd.ttf
> ./usr/share/ecore/fonts/VeraBI.ttf
> ./usr/share/ecore/fonts/VeraIt.ttf
> ./usr/share/ecore/fonts/VeraMoBd.ttf
> ./usr/share/ecore/fonts/VeraMoBI.ttf
> ./usr/share/ecore/fonts/VeraMoIt.ttf
> ./usr/share/ecore/fonts/VeraMono.ttf
> ./usr/share/ecore/fonts/VeraSe.ttf
> ./usr/share/ecore/fonts/VeraSeBd.ttf
> ./usr/lib
> ./usr/lib/libecore.so.1.0.0
> ./usr/lib/libecore.so.1
> 
> the fonts remain another issue (see last mail).

this stuff should go away. ecore should get an ecore-debug package (look what i
did with eet) which includes ecore_test, ecore_evas_test and the share files
above (as ecore_evas_test is the only thing that uses them). ecore_confg should
also be put into another package maybe ecore-util-config by itself as a utility
tool for fiddling with ecore configs. a buildrequires may suck it in for build
time for example. this should be done with evas too and all packages that
contain these binaries that are PRIMARILY library packages BUT also may include
binaries. edje is another example. u want an edje-debug (which included edje
and edje_test and all the font/png/edc/edj etc. files) an edje-cc (which
included edje_cc, edje_decc, edje_recc and the edje.inc file). also embryo is
similar (embryo in embryo-debug, the default.inc and embryo_cc in embryo-cc
package).

> i could add a virtual libecore0-all package but that shouldn't hold us
> back from adjusting proper specific ecore dependencies of apps/e, 
> apps/entrance and so on. ditto for evas when it's ready, of course.
> 
> if the previous commit in ecore is ok then i'll look into apps and libs
> which use ecore and fix the deps there.
> 
> > >
> > >>libecore0-dev will contain all available headers, as it is right  
> > >>now. or
> > >>should i split that one, too?
> > >
> > >it will have to suck in all the above libs then.
> > 
> > I think this is fine, since IMO anyone wouldn't be doing much  
> > development with only one specific subsystem of ecore.  And not to  
> > mention maintaining all those different packages for -dev AND lib  
> > will be a pain.
> > 
> i totally agree.
> 
> Falko
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic