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.

>     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".

i agree.

>     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.

indeed - see above. we may want profiles and a specific profile makes a set of
thing mandatory. :)

>     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.

we can't get away with this. we can get away with ALMOST no options.. but not
zero. the first that comes to mind is gles vs gl. today i sit here with my
desktop that has BOTH gl and gles headers and libs. which do i build for? :)
(actually i'd love to make this runtime to be honest but that will need a chunk
of code work so assuming we don't do that this has to be an option).

>      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.

i'd actually love to remove a lot of them. :)

>      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).

i agree here - this kind of thing should be all shared in terms of config. all
of efl has magic debug enabled or all of it doesn't. no pick and choose.

> -- 
> 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
> 


-- 
------------- 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

Reply via email to