On Wed, 10 Oct 2012 15:17:35 +0200 Vincent Torri <vincent.to...@gmail.com> said:
> 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. oh talking in general about all of these, not just threads. > 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) yup. this. non-optional. my pending patch to evas does this. > 3) as 2) is valid, then remove eina_inline_lock_void.x file yup. > >> - 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 ? keep for now. > >> > >> 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 at a later date - but we have openssl for this anyway. :) > >> - 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 i have done a bunch - not committed yet. > >> 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 now i am keeping them all moduels so packagers can strip them out if they want and they are now by default anyway. this is a matter for later, and its no longer a configure option. :) > >> 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
