| 1 |
On 12/05/11 10:49, Rich Freeman wrote: |
| 2 |
> On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer<patrick@g.o> wrote: |
| 3 |
>> And spend much more time trying to find them silly logfiles now that we hide |
| 4 |
>> the output. I really enjoy having to fix yet another bad default everywhere |
| 5 |
>> just so I see *why* things fail ... |
| 6 |
> Unless something has changed the logfile name including full path is |
| 7 |
> printed when there is an error. So, it is just a matter of copy/paste |
| 8 |
> into a cat and you can watch the whole thing scroll by and even |
| 9 |
> pretend it is compiling really fast while it is doing it. :) |
| 10 |
So one useless step added, which might give extra funny output because |
| 11 |
of escaped escape sequences and such funnies, with no benefit for me |
| 12 |
> |
| 13 |
> It seems like a pretty sane default to assume that most packaged build |
| 14 |
> without issues - after all, that is basically the goal, right? |
| 15 |
And for those I don't care about the output at all, but when things fail |
| 16 |
I want to see it. |
| 17 |
So for me the proper default is "show everything, let me ignore what I |
| 18 |
don't want" |
| 19 |
|
| 20 |
(Plus there are funny cases with clock skew putting builds into a loop |
| 21 |
that are obvious when you see the output, but impossible to catch with |
| 22 |
supressed output. Yey riddles!) |
| 23 |
> |
| 24 |
> That is probably why the forum post is at 52-48 - it really isn't that |
| 25 |
> obvious a call one way or the other. In any case, it doesn't affect |
| 26 |
> me anyway since I use parallel build and I trust the Council to at |
| 27 |
> least provide some kind of closure... |
| 28 |
> |
| 29 |
> Rich |
| 30 |
> |
| 31 |
Well, for the machines getting fed binpkgs it'd be an ok default, but |
| 32 |
when I build there's a pretty good chance that something funky happens. |
| 33 |
Just try FEATURES="test" emerge -e system ;) |
Archives