On Mon, 6 Aug 2012 23:45:25 +0200 Alan McKinnon <[email protected]> said:
> Top posting as I'm not really replying to your statements directly. > > I do agree with everything you said, and raster and I have had this > good-natured argument about Gentoo before. I don't know if > the argument was won but it sure wasn't by me :-) > > I just wanted to add that for the most part devs out there do a good job of > writing code and build systems. For the most part ebuild maintainers do an > equally good job of keeping ebuilds straight (we'll ignore the exceptions, > they will always be around). > > I use source distros wherever I can - Gentoo and FreeBSD. So I need > clear and explicit ./configure options without automagic dependencies. > I want to tweak software builds to support the things I want to support > in a nice safe manner without being beholden to whatever a binary > distro packager thinks I should have (I'm old school in that regard and > not likely to change...) > > Maybe the things I want are at odds with most of the rest of the > planet. e17 is well-behaved when it comes to being built, but sadly not > everything else out there has the same quality levels. If you use > Gentoo, you likely know how much automagic build crazy is in the world > (and why it is an evil that must be driven from the world and burnt to > a cinder) efl generally is well behaved.. except it is rather automagic. if u --enable something that has a dependency - and the dep is not found... the feature is disabled again (configure output tells you so at the end). some people want configure to fail in this case. ours do not - they march on and adjust config to match the environment they found. but you are right many of those options make me CRINGE. main if sections at the top: 1. xcb as an option at all. we have the support, but the problem is its not 100% complete and working. its like 98%. some key things will not work with xcb and people end up complaining to us. we know this, and that is why its not on by default. you don't have to --disable the xcb support - it's off by default. 2. the xcb options... kill gl - this is a fine and nasty detail where we CANNOT have gl support without SOME minimal xlib support. everything else except for some minimal opengl interaction is xcb, but when interfacing to glx/egl itself we use xlib. i advise that you DONT disable gl-xlib as you lose major functionality. 3. word and metric caching are off by default anyway - so no need to disable. the day these things are stable and ready for use we'll enable them by default. other use_enable flags: 4. altivec - if u are on a ppc chip.. then why NOT enable altivec? pointless to make it an option - it's detected at runtime if u don't have the instructions. 5. bidi - why just fribdi - harfbuzz is also involved in bidi support. 6. directfb - it's off by default... for a good reason. it's not maintained anymore. 7. doc - ummm ok, though docs are not BUILT unless you do "make doc" so i dont see a point of swizzling this here 8. eet - this shouldnt be an option. the rest of efl wont work without it. it's pointless making it an option as no one anywhere uses evas by itself RAW. in fact there are no docs on how to do it and the only people who really know how... are us (pretty much), so it's pretty pointless being an option. we were totally anal in making it an option to avoid people patching our builds for the rare case of some hyper-embedded environment where this may be the case (it' also a leftover from making evas toolkit agnostic thinking maybe the gnome and kde crowds wouldn't pull an NIH and go make their own scene graph canvases - but as is normal they did this again, so this is the last time we try and bother being agnostic - we're ditching the "be nice" to other toolkits mantle becuase it costs us work/effort for no gain as they don't care... "not invented here". 9. fbcon - why an option? it just needs some linux fb dev headers and that's it. no other deps. its a module file that isnt even used unless called for at runtime? 10. fontconfig ... boundary case - but frankly nothing on top of evas (elementary, e17) runs right unless you have fontconfig and sans fonts etc. so i'd highly discourage this ever being turned off (except for very very very niche cases). 11. gles - fair enough 12. gif - very useful, small dep. i'd discourage this being turned off 13. ico - no deps, just a module. useful. dont turn it off 14. jpeg - small dep. essential 15. mmx - like altivec. keep it on. runtime figures it out. 16. png - like jpeg - small dep, essential 17. ppm - no dep, useful 18. psd - no dep, useful 19. sdl - fair enough 20. sse - like altivec 21. sse3 - small catch - needs more modern gcc with sse3 intrinsics support, so ok. fair enough 22. svg - fair enough - needs esvg/enesim now... big dep chain 23. tga - no dep, useful 24. tiff - small dep, useful 25. threads - enable or disable of pthreads is a bad idea. ultra-embedded or windows support atm needs this off, but everything else should have it on. async-events, async-preload are on by default. async-render is actually now gone and removed from evas 26. X - ok. fair enough 27. xpm - no deps, useful. 28. of the res of the --enable options provides not tweakable via ricer-buttons, ALL of these are on by default, so remove them, EXCEPT for the following: --enable-static-software-generic : not tested very much. not advisable 29. the lase 3 --disable options are all off by default too, except if edb finds the edb dependency, which we frankly don't even release anymore and i'd be surprised if u have it packaged. we'll probably remove this loader soon enough. also since its a module - if it has a dep and u remove it, evas doesn't stop working totally like a lot of libraries, because modules link to the dep the feature stops working, but evas marches on. so my advice is... remove all the options except where i said "fair enough" .:) > On Tue, 07 Aug 2012 00:08:06 +0800 > P Purkayastha <[email protected]> wrote: > > > On 08/06/2012 11:39 PM, Alan McKinnon wrote: > > > On Mon, 06 Aug 2012 23:00:33 +0800 > > > P Purkayastha<[email protected]> wrote: > > > > > >> On 08/06/2012 04:45 PM, Carsten Haitzler (The Rasterman) wrote: > > >>> actually both gentoo ebuild users and the tweakers end up on our > > >>> doorstep asking us for help with their tweaked builds. on our > > >>> irc/email lists. though it's nice to help - we help again and > > >>> again and repeat ourselves that those options are for people who > > >>> know exactly what they are doing with the option. if u dont know > > >>> then accept defaults without a --enable or --disable in sight. :) > > >>> u do more than that then deal with your own problems - they never > > >>> do though. we end up with them. so the future is many fewer > > >>> options. u'll be patching src to change things and that tends to > > >>> be a barrier high enough to keep the tweakers out :) > > >>> > > >> > > >> That's not quite true. At least with *good* ebuilds in current > > >> Gentoo. *Good* ebuilds themselves provides configure options such > > >> that the default configure options are sane. For example look at > > >> the default options for evas: > > >> > > >> ~ยป eix -e evas > > >> [I] media-libs/evas > > >> Available versions: (~)1.0.1 (~)1.1.0 (~)1.2.1 > > >> (**)9999{tbz2}[1] {X altivec bidi +bmp +cache directfb doc +eet > > >> fbcon +fontconfig gif gles +ico +jpeg mmx nls opengl +png +ppm > > >> +psd sdl sse sse3 static-libs svg tga +threads tiff xcb xpm} > > >> > > >> > > >> You see all the + things? It means that those configure options > > >> (USE flags in Gentoo terminology) are all enabled by default and > > >> the rest are disabled by default. > > > > > > Hmmm, not quite. Those are the defaults for the ebuild only. > > > > > > The user may well have enabled several of those flags system-wide in > > > make.conf, such things as mmx, sdl, sse and xcb. In which case they > > > will be enabled regardless of what the ebuild says. > > > > > > Yes, that's true. But only a ricer will go ahead and enable flags > > that are destructive or not useful. If you have an old enough > > machine, you won't enable sse2, but you will probably enable sse and > > mmx. That makes sense. I don't enable sse3 on my make.conf because my > > cpu doesn't support that instruction set. On the other hand I know > > that my cpu can handle sse2 instructions, so I have enabled it. So, > > now evas, mplayer, etc can all make use of this fact. > > > > > > > Better to look at other stuff in the ebuild, like this: > > > > > > > > > > > > src_configure() { > > > if use X ; then > > > if use xcb ; then > > > ewarn "You have enabled both 'X' and > > > 'xcb', so we will use" ewarn "X as it's considered the most stable > > > for evas" fi > > > MY_ECONF=" > > > --disable-software-xcb > > > $(use_enable opengl gl-xlib) > > > " > > > elif use xcb ; then > > > MY_ECONF=" > > > --disable-gl-xlib > > > --enable-software-xcb > > > $(use_enable opengl gl-xcb) > > > " > > > else > > > MY_ECONF=" > > > --disable-gl-xlib > > > --disable-software-xcb > > > --disable-gl-xcb > > > " > > > fi > > > > > > This part is clear. If the user enables xcb (the user will have X > > enabled anyway if he selects the desktop profile), then the ebuild > > will default to X instead of xcb. This is actually good! For > > instance, elementary doesn't work with xcb (so, no 'terminology' for > > you if you forcibly disabled X for e and efl!). If the user doesn't > > have X, then the user doesn't want gl or xcb either. > > > > > > > > > > # $(use_enable cache metric-cache) > > > # $(use_enable cache word-cache) > > > MY_ECONF+=" > > > --disable-metric-cache > > > --disable-word-cache > > > $(use_enable altivec cpu-altivec) > > > $(use_enable bidi fribidi) > > > $(use_enable bmp image-loader-bmp) > > > $(use_enable bmp image-loader-wbmp) > > > $(use_enable directfb) > > > $(use_enable doc) > > > $(use_enable eet font-loader-eet) > > > $(use_enable eet image-loader-eet) > > > $(use_enable fbcon fb) > > > $(use_enable fontconfig) > > > $(use_enable gles gl-flavor-gles) > > > $(use_enable gles gles-variety-sgx) > > > $(use_enable gif image-loader-gif) > > > $(use_enable ico image-loader-ico) > > > $(use_enable jpeg image-loader-jpeg) > > > $(use_enable mmx cpu-mmx) > > > $(use_enable png image-loader-png) > > > $(use_enable ppm image-loader-pmaps) > > > $(use_enable psd image-loader-psd) > > > $(use_enable sdl software-sdl) > > > $(use_enable sse cpu-sse) > > > $(use_enable sse3 cpu-sse3) > > > $(use_enable svg image-loader-svg) > > > $(use_enable tga image-loader-tga) > > > $(use_enable tiff image-loader-tiff) > > > $(use_enable threads pthreads) > > > $(use_enable threads async-events) > > > $(use_enable threads async-preload) > > > $(use_enable threads async-render) > > > $(use_enable X software-xlib) > > > $(use_enable xpm image-loader-xpm) > > > --enable-evas-magic-debug \ > > > --enable-static-software-generic \ > > > --enable-buffer \ > > > --enable-cpu-c \ > > > --enable-scale-sample \ > > > --enable-scale-smooth \ > > > --enable-convert-8-rgb-332 \ > > > --enable-convert-8-rgb-666 \ > > > --enable-convert-8-rgb-232 \ > > > --enable-convert-8-rgb-222 \ > > > --enable-convert-8-rgb-221 \ > > > --enable-convert-8-rgb-121 \ > > > --enable-convert-8-rgb-111 \ > > > --enable-convert-16-rgb-565 \ > > > --enable-convert-16-rgb-555 \ > > > --enable-convert-16-rgb-444 \ > > > --enable-convert-16-rgb-rot-0 \ > > > --enable-convert-16-rgb-rot-270 \ > > > --enable-convert-16-rgb-rot-90 \ > > > --enable-convert-24-rgb-888 \ > > > --enable-convert-24-bgr-888 \ > > > --enable-convert-32-rgb-8888 \ > > > --enable-convert-32-rgbx-8888 \ > > > --enable-convert-32-bgr-8888 \ > > > --enable-convert-32-bgrx-8888 \ > > > --enable-convert-32-rgb-rot-0 \ > > > --enable-convert-32-rgb-rot-270 \ > > > --enable-convert-32-rgb-rot-90 \ > > > --enable-image-loader-generic \ > > > --disable-image-loader-edb > > > --disable-static-software-16 > > > --disable-software-16-x11" > > > > > > enlightenment_src_configure > > > } > > > > > > > > > > > > > > > There may well be crap in there that makes Raster cringe. > > > > You have to compare this part with the configure.ac in evas to see > > how closely the options matches the suggestions and defaults there. > > > > > > The ebuilds in enlightenment overlay are not made in random. They are > > actually pretty good and follow the defaults in configure.ac. This is > > true at least for the core packages. I don't know about other > > packages. > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions will include endpoint security, mobile security and the > > latest in malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ enlightenment-users > > mailing list [email protected] > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > -- > Alan McKinnon > [email protected] > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > enlightenment-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
