On Thu, Sep 27, 2012 at 1:19 PM, Carsten Haitzler <[email protected]> wrote: > On Thu, 27 Sep 2012 13:16:47 +0200 Vincent Torri <[email protected]> > said: > >> On Thu, Sep 27, 2012 at 12:50 PM, Carsten Haitzler <[email protected]> >> wrote: >> > On Thu, 27 Sep 2012 20:34:15 +1000 David Seikel <[email protected]> said: >> > >> >> On Thu, 27 Sep 2012 11:06:59 +0900 Carsten Haitzler (The Rasterman) >> >> <[email protected]> wrote: >> >> >> >> > On Wed, 26 Sep 2012 17:00:21 -0300 Gustavo Sverzut Barbieri >> >> > <[email protected]> said: >> >> > >> >> > > Hi all, >> >> > > >> >> > > As discussed with Vincent at IRC, and based on previous in-person >> >> > > talk with Raster and Cedric, here follows the proposal to cleanup >> >> > > the efl/ (merged) build system. >> >> > > >> >> > > PRE-NOTICE: this is the initial step and won't please everybody. If >> >> > > you're case is not in the initial proposal, bear with me that you >> >> > > can 1) keep using the split libs; 2) wait a bit until we clean the >> >> > > merge and work on your requirement/details. >> >> > > >> >> > > RATIONALE: the merge is meant to simplify the build by getting >> >> > > everything in one place and ALSO to remove the huge amount of >> >> > > options we support now as they are unmanageable. >> >> > > >> >> > > #1 - every EFL lib is mandatory: no optional builds of some >> >> > > components. >> >> > > >> >> > > This removes lots of complexities from both configure.ac and >> >> > > Makefile.am. All the "want_XYZ" should go from configure.ac, we >> >> > > just need minimal checks to add platform specific dependencies >> >> > > (evil, exotic, eeze). >> >> > >> >> > hmm this may cause problems - eg we raise the bar of dependencies of >> >> > elementary where someone was building and intending to package only >> >> > up to edje. they now have to satisfy elementary deps in order to just >> >> > get a subset packaged. (yes i know we can split at packaging time >> >> > rather than enable/disable at build time - i'm assuming we move >> >> > splitting off to packagers). what may make sense is just some minimal >> >> > enables/disables - eg --disable-rendering and --disable-gui so you >> >> > can build an efl that is only eina, eet, eeze, edbus, ecore, efreet >> >> > for example for back-end work (servers), or then add rendering stuff >> >> > (embryo, edje, evas) but with no display system deps (ie rendering to >> >> > memory only), and then full gui. this kind of division of what can be >> >> > enabled or disabled may make the most sense. >> >> > >> >> > > #2 - every dependency is mandatory: no more optional libjpeg, >> >> > > fontconfig and so on. No more "automagic" detection that silently >> >> > > causes problems for 99% of users (why can't I see text in e17? why >> >> > > can't I view png?) >> >> > >> >> > we may need to create profiles as above - like "server", "middleware" >> >> > and "ui" or something. but i agree that these should become at LEASt >> >> > mandatory in that UNLESS u --disable - configure fails. and the >> >> > default profile is ui. ie everything. >> >> >> >> Much better idea than what you replied to me elsewhere in this >> >> thread. Include an "embedded" profile and I'm sold on it. B-) >> > >> > it may not match your idea of embedded - so u'll have to live with it or do >> > what i already said - package up only the bits u need. >> >> what about an option that list all the efl we want, separated by a token, >> like >> >> --with-efl=eo,***,ecore-con >> >> to select exactly what the user wants (instead of a bunch of >> --en(dis)able options) ? > > --with-profile=server,embedded,full > > ?:)
if you want *also* such option, no problem :p Vincent ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
