Hello. On Wed, 2014-06-11 at 13:31, Daniel Kolesa wrote: > 2014-06-11 13:22 GMT+01:00 Stefan Schmidt <ste...@datenfreihafen.org>: > > > Hello. > > > > On Thu, 2014-06-05 at 14:51, Daniel Zaoui wrote: > > > Bon travail, mon ptit frileux! > > > > > > On 06/05/2014 02:42 PM, Guillaume Friloux wrote: > > > > kuri pushed a commit to branch master. > > > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id=3ed4f745907d3e842e64b341e2426c0c99cf3297 > > > > > > > > commit 3ed4f745907d3e842e64b341e2426c0c99cf3297 > > > > Author: Guillaume Friloux <guillaume.fril...@gmail.com> > > > > Date: Thu Jun 5 13:40:44 2014 +0200 > > > > > > > > Add --disable-gui. > > > > > > > > This allows people to disable the building of anything GUI related. > > > > In my case, it is used for servers. > > > > > > > > I encourage anyone that think they can do a better patch to > > improve it, > > > > as i dislike having to add all those AM_CONDITIONAL(). > > > > > > > > Maybe the macros should be improved. > > > > --- > > > > configure.ac | 204 > > ++++++++++++++++++++++++++++++++++++++++------- > > > > data/Makefile.am | 3 + > > > > doc/previews/Makefile.am | 3 +- > > > > src/Makefile.am | 26 +++--- > > > > 4 files changed, 194 insertions(+), 42 deletions(-) > > > > What are we going to do with this now? Even if people disagreed it was > > not reverted. > > > > Who is going to keep an eye on this? I'm not happy about having more > > complexity and maybe a half baked solution in here. Especially not if > > the person who did it and had interest in it quit the project a few > > days later. > > > > I would like to see others that want this feature to speak up now and > > work on a solution. Only speaking up and saying I want this will not > > work out here. Someone needs to do the work and to have an eye on it > > to makes sure it will keep working. > > > > If we find nobody doing this job I would propose to revert this change > > as it would imply that nobody cares enough and the complexity would be > > to much imho. > > > > I would revert the change for now (as Kuri quit) but in longer term (not > crucial atm, but would be nice to have) I'd be looking for a proper > solution to this problem - something less "hardcoded" - as different people > might want different sets of modules enabled, when not building all.
I nobody screams I will revert it tomorrow. As for the longer term I have to say I'm skeptical if we find a middle ground between complexity and usefullness here. Everyone that complained about the merge had a different niche profile they wanted to support. While I'm skeptical I'm not against it if this is done well and complexity kept down. If you want to do this maybe start with some use cases people would like to cover with this. regards Stefan Schmidt ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
