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

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: signature.asc
Description: PGP signature

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