On Wed, Oct 10, 2012 at 2:54 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt <s.schm...@samsung.com> > said: > >> Hello. >> >> On 10/10/12 08:12, Carsten Haitzler (The Rasterman) wrote: >> > >> > what i want is for everyone please to test the efl tree and look at >> > configure options and find things to clean up/remove/whatever. i already >> > think we need to remove much more. >> >> Magic checks, debug and log level left out here as they seem to be >> handled by profiles. Should valgrind support also be handled with this? >> >> Unit tests, coverage and benchmark will be enabled for all libs at once >> I suppose. >> >> Eina: >> - Remove threads configure option (on by default) > > i already sent a mail about a lot of these about 2 weeks back. :)
if there is an option, then i have forgotten to removed it. Currently, it's auto detected. things to do: 1) remove option is it's still there 2) make threads not optional (configure fails if no thread support is found, requested by raster) 3) as 2) is valid, then remove eina_inline_lock_void.x file >> - Remove mempool configure options >> - For Iconv, dirfd, xattr and shm_open I would also think remove the >> configure option and set on by default. But I'm surely not seeing all >> implications for these and have no hard feelings here. :) there is an option to explicitely set the iconv library name. I remove it ? >> >> Eet: >> - GnuTLS might need to stay. My feelings here are that not enough people >> use this feature to justice the overhead of the default linkage with >> gnutls. But we could at least have one option instead of cipher and >> signature. > > th only thing here to consider is removing gnutls support entirely - but here > comes the catch. some distros refuse to use openssl because its "non-free" as > technically its licensing is claimed to be "incompatible with gpl" or > something. :( and it should be fixed as, on windows, because of the libgcrypt stuff horror, it does not compile and I have to disable the secure layer. Maybe this part of the code should be rewritten, using different files for gnutls and openssl, insteadd of plenty of #ifdef >> - Remove old eet file format option (on by default) > > not until 2.0 :( > >> > what we also need to do is strip down configure options for evas, and ecore >> > and the rest of efl where needed, so feel free to look at that. i intent to >> > poke around evas soon., but the current efl tree needs yet more options >> > nuked imho. :) >> >> Evas is a real beast when it comes to configure options. :) > > yes. i plan to nuke most of them. before the merge, please >> The first thing that jumps into my eye are the ARGB Conversion Options. >> Having them all on by default would really be so much overhead? I mean >> you don't use them it should be fine to just always build them. > > that was me being anal about evas being really small for embedded - but evas > is > now much bigger and it makes little sense to have only some - my plan is to > enable all of them. the only issue is dither mask as the 128x128 dither mask > does add a fair chunk of library file size and is slower than ordered or line > dither. i will keep this - at least for now. > >> Image loaders are way more complicated sadly as we drag in dependencies >> here. I would vote for making jpeg, png, gif, bmp, eet on by default. > > right now all loaders are auto or on by default. loaders with no dependencies > i > plan on making always on - no option to turn them off at all (you don't want > them then delete the module files after install). bmp has no deps so its one > of > these always on ones. what about making even static for jpeg and png at least (jpeg is already a hard dep of eet anyway and png is uber-common) ? Don't know for eet one. >> For the others we might need to see what libs distros ship in a default >> installation so we can decide if we have a hard dep on these libs or not. > > jpeg can be on by default - same with eet. in fact no option to turn off. eet > needs jpeg - no option. i think i'll make png a hard-dep too. the rest that > have deps will have to be like they are now. > >> That should clear things up a lot. (Yes, I left out engines here on >> purpose. Don't wanted to fight over them :)) > Vincent ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
