On Fri, 12 Oct 2012 15:54:44 +0200 Thomas Sachau <to...@gentoo.org> said:
> Carsten Haitzler (The Rasterman) schrieb: > > On Wed, 10 Oct 2012 21:52:30 +0200 Thomas Sachau <to...@gentoo.org> said: > > > >> Tom Hacohen schrieb: > >>> On 10/10/12 11:11, Stefan Schmidt wrote: > >>>> Hello. > >>>> > >>>> On 10/10/12 10:04, Tom Hacohen wrote: > >>>>> On 10/10/12 11:00, Stefan Schmidt wrote: > >>>>>> Hello. > >>>>>> > >>>>>> On 10/10/12 09:50, David Seikel wrote: > >>>>>>> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt > >>>>>>> <s.schm...@samsung.com> wrote: > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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. > >>>>>>> > >>>>>>> Better would be to remove the options, but detect them at build time > >>>>>>> to see if they should be included. Things should never be hard > >>>>>>> dependencies, unless they actually are. > >>>>>> > >>>>>> I see that you don't want to have this for your embedded project. :) > >>>>>> > >>>>>> But I disagree here. Autodetection is even worse in the case for the > >>>>>> image loaders as your application will fail during runtime to load a > >>>>>> theme or display thumbnails, etc. In your strictly controlled env this > >>>>>> is not a problem as you can only blame yourself but in my opinion this > >>>>>> is a no-no for almost all other users. Thus I would vote against > >>>>>> autodetection and choose the hard deps carefully to fit the majority of > >>>>>> our users. > >>>>> > >>>>> I'm also against autodetection. I prefer strict option setting. But you > >>>>> want to have them (all?) on by default and just let people disable them > >>>>> if needed. > >>>> > >>>> This would defeat the original purpose of removing options, right? :) > >>>> > >>>> regards > >>>> Stefan Schmidt > >>>> > >>> > >>> I think the ideas is to remove useless options, not useful. :) > >>> I'm not really against it, I'm fine with automagically detecting stuff > >>> if packagers don't find this annoying, the real question is: do they? > >> > >> Of course they do. automagic does mean, that you cant control, what > >> actually happens, so you will never know, what a specific package will do. > >> > >> Just a basic example: > >> > >> Optional dependency installed, automagic package sees it, uses it, but > >> user/developer/packager does not notice it, later the optional > >> dependency gets removed. The result: broken automagic package and no way > >> to properly fix this. > > > > for someone doing rpm pkging... you should know that this wont happen > > because rpm does auto deps... it ldd's everything looking for deps. > > > > As you can see in my sig, i do work on Gentoo Linux and until now, i > dont create rpms but instead ebuilds, so this is no valid point. ;-) sorry sory - my bad... i'm confusing thomas's - tomas chech (no h in tomasand different last name). sorry - too many t(h)omas's on my brain :) > Beside that, it is also a valid point for creation of rpms, since the > list of dependencies and features will then change, always depending on > the currently installed list of optional dependencies of the packager. sure - but ropm will get the current set of deps right and encode that in the rpm. > So if someone starts with a minimal system, he will have all optional > features disabled, and a new build of the package later on with more > optional packages installed would create a different result, since it > includes more optional features and more dependencies. correct. there is a --enable-strict that forces deps to be strictly checked if you enabale them and thus cause a build error - this was put it for packagers, but the default is to make regular devs and users happy in that it just auto-enables or disables based on what you have to provide minimal build issues. > So again someone would have to check the build system itself for > optional automagic dependencies, install them all before building > packages for efl, just to be sure to always have the same result. And > again, just forcing those dependencies would make it much easier for the > packager, since the result does not vary depending on the current set of > installed optional dependencies. > > So again: Either force-disable/force-enable a feature or allow configure > switches for it, automagic just causes more confusion and more work for > packagers and users. more for packagers. less for users. users have their stuff mostly "just work" in terms of build. they may or may not have certain features and these are checked for later at runtime anyway, but we are making more core features not even able to be disabled in the efl tree anyway - so these wont need runtime checks as much but the rest is still automagic unless u enable the strict stuff as above - if you are a packager then go do that. :) > -- > > Thomas Sachau > Gentoo Linux Developer > -- ------------- 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
