655
|
1 |
SCANLOG.PL
|
|
2 |
17/02/2003
|
|
3 |
|
|
4 |
1. Introduction
|
|
5 |
|
|
6 |
scanlog.pl is a utility for summarising a build log. It reports the time
|
|
7 |
taken for each phase of the build, and the numbers of fatal errors and warnings.
|
|
8 |
For each component, the numbers of warnings and errors are accumulated across
|
|
9 |
all phases and reported by component.
|
|
10 |
|
|
11 |
|
|
12 |
2. Log file format
|
|
13 |
|
|
14 |
scanlog expects the logfiles to have a particular structure for identifying
|
|
15 |
the phases and components. It will tolerate log files which don't fully conform
|
|
16 |
to this structure, but the reporting will have less detail.
|
|
17 |
|
|
18 |
The expected structure is:
|
|
19 |
|
|
20 |
===-------------------------------------------------
|
|
21 |
=== <command for the phase>
|
|
22 |
===-------------------------------------------------
|
|
23 |
=== <phase> started Fri Feb 7 12:47:28 2003.
|
|
24 |
=== <phase> == <component1>
|
|
25 |
... build output
|
|
26 |
=== <phase> == <component2>
|
|
27 |
... build output
|
|
28 |
=== <phase> == <componentN>
|
|
29 |
... build output
|
|
30 |
=== <phase> finished Fri Feb 7 13:13:41 2003.
|
|
31 |
|
|
32 |
<phase> should be a single word without spaces, for example "target".
|
|
33 |
The timestamps are optional and not processed by the current version of scanlog,
|
|
34 |
though they are being processed by other tools.
|
|
35 |
|
|
36 |
For this example, scanlog would summarise this part of the log as
|
|
37 |
|
|
38 |
<command for the phase> 00:26:13 0 0
|
|
39 |
|
|
40 |
assuming that there are no errors or warnings detected.
|
|
41 |
|
|
42 |
|
|
43 |
3. Errors and Warnings
|
|
44 |
|
|
45 |
Scanlog uses a set of regular expressions to identify lines in the log file
|
|
46 |
which are usually associated with errors or warnings, for example:
|
|
47 |
|
|
48 |
/make(\[\d+\])?: \*\*\* / -- e.g. make[2]: ***
|
|
49 |
|
|
50 |
which is the way that GNU make reports a failure.
|
|
51 |
|
|
52 |
This rather simple approach can overstate the number of errors, particularly
|
|
53 |
given the nested makefile approach used by the Symbian build tools. It is
|
|
54 |
counting the symptoms of a failure rather than necessarily identifying the
|
|
55 |
root cause.
|
|
56 |
|
|
57 |
Errors are warnings are summarised according to the build phase (described above)
|
|
58 |
and also accumulated across build phases and reported by component. If scanlog
|
|
59 |
is invoked with the additional -V argument, the lines counted as warnings and
|
|
60 |
errors are reported for each component, to aid problem diagnosis.
|
|
61 |
|
|
62 |
|
|
63 |
4. Things not built...
|
|
64 |
|
|
65 |
Scanlog also looks for lines which begin with "MISSING: ", which are normally
|
|
66 |
produced by the output of "abld -check build". The missing files are listed and
|
|
67 |
marked with the component which reported them, serving as an additional view of
|
|
68 |
what has actually failed if fatal errors are reported.
|
|
69 |
|
|
70 |
|
|
71 |
5. List of patterns
|
|
72 |
|
|
73 |
Scanlog originally just looked for errors and warnings arising from the structure
|
|
74 |
of the Symbian build, but has increasingly gained patterns to detect output from
|
|
75 |
specific tools such as the ARM RealView compiler. This contributes to the "over
|
|
76 |
counting" of errors, but provides more useful "scanlog -V" output.
|
|
77 |
|
|
78 |
Scanlog uses these patterns to identify errors:
|
|
79 |
|
|
80 |
/^MISSING COMPONENT (.*):.* find (.*)$/
|
|
81 |
/(ABLD|BLDMAKE) ERROR:/
|
|
82 |
/FATAL ERROR\(S\):/
|
|
83 |
/fatal error U1073: .* make '(.*)'/
|
|
84 |
/fatal error U1077/
|
|
85 |
/warning U4010/
|
|
86 |
/make(\[\d+\])?: \*\*\* /
|
|
87 |
/make(\[\d+\])?: .* not remade /
|
|
88 |
/"(.*)", line (\d+): (Error: +(.\d+.*?):.*)$/
|
|
89 |
/error: ((Internal fault):.*)$/
|
|
90 |
/Exception: STATUS_ACCESS_VIOLATION/
|
|
91 |
/target .*? given more than once in the same rule/
|
|
92 |
/^ERROR: /
|
|
93 |
|
|
94 |
The "warning U4010" pattern catches lines such as
|
|
95 |
|
|
96 |
NMAKE : warning U4010: 'FINALCOPYFXCM' : build failed; /K specified, continuing ...
|
|
97 |
|
|
98 |
which would arise from the use of nmake /k in situations which would otherwise
|
|
99 |
be fatal errors.
|
|
100 |
|
|
101 |
|
|
102 |
Scanlog uses these patterns to identify warnings:
|
|
103 |
|
|
104 |
/Warning: Unmatched/i
|
|
105 |
/^BLDMAKE WARNING:/
|
|
106 |
/WARNING\(S\)/
|
|
107 |
/^WARNING: /
|
|
108 |
/\(\d+\) : warning C/
|
|
109 |
/LINK : warning/
|
|
110 |
/:\d+: warning:/
|
|
111 |
/"(.*)", line (\d+): (Warning: +(.\d+.*?):.*)$/
|
|
112 |
/^MAKEDEF WARNING:/
|
|
113 |
/ERROR: bad relocation:/
|
|
114 |
/mwldsym\d+.exe: warning:/
|
|
115 |
/^(\d+) warning/
|
|
116 |
/mwld.exe:/
|
|
117 |
/^Command line warning/
|
|
118 |
/Usage Warning:/
|
|
119 |
|
|
120 |
The "ERROR: bad relocation" pattern catches messages from petran which are actually
|
|
121 |
just warnings, for example:
|
|
122 |
|
|
123 |
ERROR: bad relocation: [00004f60] = 00000f68
|
|
124 |
|
|
125 |
Petran follows a heuristic in these cases, and to date there has never been a
|
|
126 |
runtime error attributed to this warning.
|
|
127 |
|