| 1 |
El sáb, 05-11-2011 a las 21:03 -0600, Ryan Hill escribió: |
| 2 |
> On Sat, 5 Nov 2011 21:00:32 +0100 |
| 3 |
> Maciej Mrozowski <reavertm@×××××.com> wrote: |
| 4 |
> |
| 5 |
> > > I've seen too many bugs reports today that gave me cute, colorful |
| 6 |
> > > build.logs and almost no information about underlaying bug... |
| 7 |
> > |
| 8 |
> > That's usually because users sometimes attach only "relevant" parts of build |
| 9 |
> > log (well, relevant according to their taste = last lines, even when they use |
| 10 |
> > parallel compilation). |
| 11 |
> |
| 12 |
> I think you're confusing build log with build output. |
| 13 |
> |
| 14 |
> > Any particular example of bug report with entire build log from cmake-utils in |
| 15 |
> > fancy mode, and still being unable to locate the problem? |
| 16 |
> > |
| 17 |
> > I ask, because we're appending summary just after configure phase to make |
| 18 |
> > vorbose logging of whole build process unecessary. |
| 19 |
> |
| 20 |
> How are you supposed to debug a compile or linker error without the compiler |
| 21 |
> command line? |
| 22 |
> |
| 23 |
> |
| 24 |
|
| 25 |
How all this ended up? It would still be nice to have verbose output |
| 26 |
enabled by default (even people being able to use emerge --quiet to |
| 27 |
silent it) to check for undesired flags (like -Werror, |
| 28 |
-DG_DISABLE_DEPRECATED...) easily :) |
Archives