On Wed, Sep 26, 2012 at 10:00 PM, Gustavo Sverzut Barbieri <[email protected]> wrote: > 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.
i do not agree 1) it's not complicated at all, and easily maintainable (i already do it...) It's a matter of 3 or 4 lines in configure.ac... 2) having 0 option is just non sense. Having a plethore of options can indeed be a problem 3) if you do that, then esvg can not be used as svg rendering library. So a problem at evas stage... Vincent > > 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). > > > #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?) > > This removes lots of complexities from both configure.ac and helps > packagers (see my complaints about packaging EFL on a live system, which > Gentoo users suffer). This also helps people to have the same set of > features everywhere, avoiding bugs like "I can't load font because I had > fontconfig package, but no fontconfig-dev". > > In future we may review some of the mandatory libraries. Things like > glib, gnutls/openssl will likely become optional in near future. This is a > case for embedded folks doing custom slim systems. > > QUESTION: how to do the pkg-config checks? Should we > PKG_CHECK_MODULE([JPEG], [libjpeg]) and use it everywhere or do > PKG_CHECK_MODULE([EVAS], [all deps here])? > > > #3 - start with zero options. > > Similar to #2, this cuts configure.ac by a big amount and even > Makefile.am will be simplified. In a similar way we guarantee the EFL have > the same set of features everywhere, avoiding bugs and user reports. > > As well as #2 we may review this in future, either by adding > --enable-OPTION or by allowing users to specify a custom/hand-made config.h > that defines the options. > > The code is not being changed to remove #ifdef, at least not initially. > > Work: remove all symbols from configure.ac that starts with libname, > for example EINA_CONFIGURE_MAGIC_DEBUG, EINA_SAFETY_CHECKS, > EINA_LOG_LEVEL_MAXIMUM, EINA_CONFIGURE_HAVE_STDINT_H. Later if we add the > symbol, it will be used for EVERY library (if you disable magic debug, it's > disable for every library). > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
