On Wed, 12 Feb 2014 08:42:13 -0600 Austin Morgan <admor...@morgancomputers.net> said:
> On Wed, Feb 12, 2014 at 08:53:37AM +0900, Carsten Haitzler wrote: > > On Tue, 11 Feb 2014 22:45:30 +0200 Alan McKinnon <alan.mckin...@gmail.com> > > said: > > > > > On 11/02/2014 17:41, Carsten Haitzler (The Rasterman) wrote: > > > > On Tue, 11 Feb 2014 15:27:43 +0200 Alan McKinnon > > > > <alan.mckin...@gmail.com> said: > > > > > > > >> On 11/02/2014 10:28, Mick wrote: > > > >>> On Monday 10 Feb 2014 13:27:00 Jesús J. Guerrero Botella wrote: > > > >>>> Well, I don't have any problem with using whatever is suggested > > > >>>> upstream. The thing with USE flags is that they can be set globally, > > > >>>> and when an ebuild has an USE flag to enable or disable a given > > > >>>> feature you are supposed to be able to use that, that is, unless the > > > >>>> ebuild has an ewarn about it or the USE is masked. I try to make use > > > >>>> of the documentation when available, however this time I neglected > > > >>>> to do so, mostly because a hard lock is not something that's usually > > > >>>> documented and partly because, to start with, I didn't even know > > > >>>> where to start looking. > > > >>> > > > >>> I'm going from memory here but recall that when I tried to emerge efl > > > >>> portage warned me about having xcb set. So I unset it and off it went > > > >>> completing the emerge. > > > >> > > > >> >From efl-1.8.5.ebuild (in part): > > > >> > > > >> REQUIRED_USE=" > > > >> X? ( !xcb ) > > > >> " > > > >> > > > >> USE="X xcb" is enabled by default in the desktop profile so you will > > > >> get that warning and are forced to disable one of them when emerging > > > >> efl for the first time. For other profiles USE="xcb" is usually off, > > > >> so enabling it produces the same error message. > > > >> > > > >> Most folks would think long and hard before setting USE="-X". > > > >> Perhaps the enlightenment herd can add an elog to clarify that not only > > > >> must one choose between X|xcb, but that xcb is completely unsupported > > > >> upstream so YMMV, break, both halves, keep + kittens => eaten > > > > > > > > efl 1.9 has a big paragraph that configure blurts out about this... and > > > > it sleeps for 10sec do make you notice the pause and display... > > > > > > Your average Gentoo user won't see that message - we tend to set the > > > build up then walk away and let the build framework do it's thing. The > > > packager ought to see it as by rights they are supposed to eyeball stuff > > > before declaring it fit for consumption. > > > > > > Can I make a suggestion? > > > > > > configurable options for efl and e tend to fall into two camps - solid, > > > stable, supported stuff; and everything else that's there for who knows > > > what reason. Xcb looks and feels like a moribund option that went in > > > when someone worked on it, and is sorta still there. > > > > > > Why not just rip all that other stuff out of main? As you say, no-one > > > important runs it or tests it. Leave it in a testing/dev branch by all > > > means so someone up for the job can check it out and work on it. > > > > > > Reason being, when I see this: > > > > > > $ ./configure --help=short > > > ... > > > --with-x11=xlib|xcb|none > > > X11 method to use: xlib, xcb or none > > > > > > then I expect all offered options to work as intended and be release > > > quality. If I want to play with badass unsupported magic, I don't expect > > > you to ship it, I do expect to do the heavy lifting myself of fetching > > > diffs and patching first. > > > > > > Happily, it looks like a lot of the strange option that were in efl-17 > > > are now gone already, so thank you for that. > > > > and that then leads to insane/major bitrot once it goes into a branch. xcb > > works for 99% of stuff... until you start bringing opengl into things. then > > it gets tricky. how about gentoo stop offering every --enable/disable > > feature on the planet just because it can? that's my suggestion. i think > > i'll ADD another option you have to pass and make configure fail without > > it. that'll break the ebuilds and i'm super happy about that. :) > > > Because I build embedded gentoo systems sometimes and have actually used > xcb as described above. I agree that xcb should be disabled by default > with a very strongly worded warning. Warnings are grouped and displayed > at the end of a build so you don't have to sit there watching your > screen. I will go one step further and submit a patch to implement both > of these steps tonight. i did it already. see configure.ac - any option we deem as "not healthy" i've added a warning blob to at the end summarising everything configure doesn't like, and it fails... unless you then ALSO add: --enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aaa it still has a 10 second pause here even if you do provide this option. so you CAN configure things the way you want, but i've added a loud warning siren with an extra safety lock you ALSO have to unlock. that "aaa" at the end we'll keep swizzling about each efl release to ensure that upgrades that go through a build system that enables things that are dangerous break and need to be "fixed". it's a reminder so you can't just throw this in your ebuild/packaging once and then forget about it forever. it'll keep you on your toes. for an embedded build where you likely stick to one version of efl for a product/thing this should be minimal pain and get you what you want, but it will catch out all the other tweakers who don't know what it is that is being asked of the build if they go swizzle options. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
