On Thu, 27 Sep 2012 10:25:24 -0300 Lucas De Marchi <[email protected]> said:
> On Wed, Sep 26, 2012 at 11:06 PM, Carsten Haitzler <[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. > > > Agreed. --disable-rendering, --disable-gui are indeed good options. > > > > >> #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. > > would a profile be a set of --disable-XXX? i was literally thinking a profile - eg --with-profile=full --with-profile=server etc. etc. - only need 3 or 4 profiles going from minimal backend with zero gfx thru to rendering but no windowing systems to full gui - maybe striped down gui. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
