[PATCH] Fix 'build_max_size_human' ref. before assignment

[Sebastian Huber]

On 16/01/2019 07:05, Sebastian Huber wrote:
> On 16/01/2019 02:27, Chris Johns wrote:
>> On 15/1/19 11:31 pm, Sebastian Huber wrote:
>>> On 13/01/2019 23:17, Chris Johns wrote:
>>>> On 14/1/19 8:05 am, Chris Johns wrote:
>>>>> On 11/1/19 4:31 pm, Sebastian Huber wrote:
>>>>>> ----- Am 11. Jan 2019 um 0:11 schrieb Chris Johns chrisj at rtems.org:
>>>>>>
>>>>>>> On 10/1/19 11:17 pm, Sebastian Huber wrote:
>>>>>>>> This patch resulted in this mail report issue:
>>>>>>>>
>>>>>>>> Your mail to 'build' with the subject
>>>>>>>>
>>>>>>>>       Build Linux: FAILED 6/rtems-epiphany on x86_64-linux-gnu
>>>>>>>> (epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1) 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Is being held until the list moderator can review it for approval.
>>>>>>>>
>>>>>>>> The reason it is being held:
>>>>>>>>
>>>>>>>>       Message body is too big: 1093190 bytes with a limit of 
>>>>>>>> 256 KB
>>>>>>>>
>>>>>>> Are you asking for the size limit on the list to be raised?
>>>>>> No, but is this the normal size for a failed report?
>>>>>>
>>>>> It should not be. I will accept the post and then we can see the 
>>>>> reason.
>>>>>
>>>> The report captures the last part of the build and it looks like 
>>>> the lines in
>>>> the section of the libstdc++ library being built are long. The use 
>>>> of full
>>>> length hashes in gcc and newlib has increased the path lengths.
>>>>
>>>> I increased the number of lines captured a while ago because the 
>>>> number of cores
>>>> being used when building meant distance in the output between the 
>>>> error and the
>>>> end of the log can be a long way.
>>>>
>>>> Maybe a smarter parser should be added and just the error logged?
>>> When I look for tool chain build errors I simply go to the end of 
>>> the log file
>>> and then search backwards for "error:".
>>>
>> There are linker and I think assembler errors which do not work as 
>> well ...
>>
>> https://git.rtems.org/rtems-tools/tree/tester/rt/check.py#n447
>
> Ok, it is not that simple. I guess we have to improve this each time 
> we see a 1MiB error log context.
>

It seems Ada build errors are quite difficult to identify. What worked 
quite well is searching for "make.*Error" from the top of the file.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.