On Fri, Mar 05, 2010 at 08:17:48AM +1100, Carsten Haitzler wrote: > it is an argument.. why? because it's our code. our repository. those bugs > have > existed - i remember vaguel working on it - no, i didn't have a link- hell i > dont think i had a link at the time. it was discovered, fixed so it worked and > did no harm, then we moved on.
Just in case, if we will provide working autofoo scripts (patches or etc) for some package, that keeps in general same behaviour as original has - will you apply them? I'm speaking now about so called 'automagic', when particular packages (including core ones, like ecore or eina) switching off/on some features depending on existence of some packages and user can't explicitelly request or disable this checks and builds. Also, there is a problem with 'e' - as you've merged most of usefull modules inside e itself, now it is very difficult to switch off/on some module (you will be forced to rebuild whole e to get just one module additional). If we will provide autofoo scripts with recursive configures, that will allow to fetch and build single module without e itself, while keeping possibility of controlling build options for whole e - will you accept this, or you will say "it may break someday, current scheme is working, let's not change it, as we don't want to test your new scripts"? ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
