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. :) > - 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. :) > > 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. :( > - 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. > 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. > 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 :)) i think engines will stay as they are now. :) > regards > Stefan Schmidt > > ------------------------------------------------------------------------------ > 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
