| 1 |
Neil Bothwick wrote: |
| 2 |
> On Fri, 20 Jan 2012 04:08:57 -0600, Dale wrote: |
| 3 |
> |
| 4 |
>>>> Sometimes my problem is it is like shooting skeet, it's a |
| 5 |
>>>> moving target. Sometimes it moves pretty darn fast too. Zac |
| 6 |
>>>> adds it faster than I can keep up. I wish they would |
| 7 |
>>>> announce new stuff when it get released, both unstable and |
| 8 |
>>>> stable. Then again, maybe it moves so fast he can't keep up |
| 9 |
>>>> either. lol |
| 10 |
>>> |
| 11 |
>>> --changed-use has been around for many years. |
| 12 |
> |
| 13 |
>> It sounds like the way it works has changed tho. I don't think I |
| 14 |
>> have used that option before so I don't know how it used to work. |
| 15 |
>> I think the OP thinks the same. Something changed I guess. We |
| 16 |
>> all know that after the build output disappeared a while back. |
| 17 |
> |
| 18 |
> It hasn't changed and generally works as expected. I suspect this |
| 19 |
> is specific to the KDE ebuilds (or eclass). changed-use should only |
| 20 |
> skip an ebuild with changed flags if re-emerging would produce |
| 21 |
> exactly the same code as before, this may not be the case. For |
| 22 |
> example, in some ebuilds, it is the absence of a USE flag that |
| 23 |
> triggers an extra configure option, so removing that use flag would |
| 24 |
> give the same code as if the package had been emerged with it |
| 25 |
> enabled. |
| 26 |
> |
| 27 |
> Something like this happened recently with the nls flag on glibc. |
| 28 |
> |
| 29 |
> |
| 30 |
|
| 31 |
|
| 32 |
I'll take your word for it. ;-) |
| 33 |
|
| 34 |
Dale |
| 35 |
|
| 36 |
:-) :-) |
| 37 |
|
| 38 |
-- |
| 39 |
I am only responsible for what I said ... Not for what you understood |
| 40 |
or how you interpreted my words! |
| 41 |
|
| 42 |
Miss the compile output? Hint: |
| 43 |
EMERGE_DEFAULT_OPTS="--quiet-build=n" |
Archives