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.
--
Alan McKinnon
alan.mckin...@gmail.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
