[rtems-source-builder commit] 5: Update to Binutils 2.30

[Sebastian Huber]

On 29/01/18 22:40, Chris Johns wrote:
> Hi Sebastian,
>
> Can you please post RSB patches to the devel list so I can review them?

Since this was a minor follow up patch of

https://lists.rtems.org/pipermail/devel/2018-January/020072.html

and Joel already announced the Binutils 2.30 release I thought that it 
is ok to check this in without review.

>
> On 30/1/18 12:00 am, Sebastian Huber wrote:
>> Module:    rtems-source-builder
>> Branch:    master
>> Commit:    6d9c77c77d271d1fc2dfe8493d6713930b52a6dd
>> Changeset: http://git.rtems.org/rtems-source-builder/commit/?id=6d9c77c77d271d1fc2dfe8493d6713930b52a6dd
>>
>> Author:    Sebastian Huber <sebastian.huber at embedded-brains.de>
>> Date:      Mon Jan 29 07:23:54 2018 +0100
>>
>> 5: Update to Binutils 2.30
>>
>> ---
>>
>>   rtems/config/5/rtems-default.bset     |  2 +-
>>   rtems/config/5/rtems-epiphany.bset    |  2 +-
>>   rtems/config/5/rtems-m32c.bset        |  2 +-
>>   rtems/config/5/rtems-or1k.bset        |  2 +-
>>   rtems/config/5/rtems-riscv32.bset     |  2 +-
>>   rtems/config/5/rtems-riscv64.bset     |  2 +-
>>   rtems/config/tools/rtems-binutils.cfg | 27 +++++++++++++++++++++++++++
>>   7 files changed, 33 insertions(+), 6 deletions(-)
>>
>> diff --git a/rtems/config/5/rtems-default.bset b/rtems/config/5/rtems-default.bset
>> index 1056e2c..bb1a123 100644
>> --- a/rtems/config/5/rtems-default.bset
>> +++ b/rtems/config/5/rtems-default.bset
>> @@ -10,7 +10,7 @@
>>   5/rtems-autotools
>>   
>>   devel/expat-2.1.0-1
>> -tools/rtems-binutils-2.29-1
>> +tools/rtems-binutils
> I am confused or there is some confusion. I agreed to changing
> 'tools/rtems-binutils-2.29-1' to 'tools/rtems-binutils-2.29', that is removing
> the RSB revision number but not the version of the tool set. I appreciate the
> drive to a "single definition" however the cost/benefit trade off is subjective
> and I do not think it is there in this last change.

Ok, then I misinterpreted:

https://lists.rtems.org/pipermail/devel/2018-January/020020.html

>
> I cannot see a way around needing the 'tools/*' files with archs on different
> versions of tools. The design is for bsets files to change and not 'tools/*'
> with the patchs and hashes as this data is fixed for the version of the tools.
>
> This change means I need to check in 3 places and 2 directions for a version. To
> check a version I now need to check to the bset file to see if it is on the
> 'defaults', then the default is the "nominal" version and then the "nominal" file.
>
> It has also introduced consistency in the file naming and usage. I understand
> you want a single place to make a change but this approach breaks down when all
> arch's are not in the same version, you need specific specific tool/* file
> versions as we have and this means the approach is inconsistent and I favor
> consistency.
>
>
>>   tools/rtems-gcc
> I must have missed this change as well.
>
> I prefer and would like to maintain the versions of the tool in the 'tool/*
> name. We have never had all archs on the same set of tools.
>
> Sorry, I do not agree with these name changes.

Now you have to edit

tools/rtems-binutils.cfg

if you want to update the Binutils. For GCC you have to update

tools/rtems-gcc.cfg

or very unlikely

tools/rtems-gcc-m32c.cfg
tools/rtems-gcc-or1k.cfg

For Newlib you have to  update

tools/rtems-gcc.cfg
tools/rtems-gcc-m32c.cfg
tools/rtems-gcc-or1k.cfg

You don't have to touch the *.bset files.

If we go back to the versions in the file names then we have to update 
also the *.bset files and we create orphan files with each version 
update. I don't really care which variant we use since the frequency of 
these changes is quite low. What should I do now? Add the versions to 
the files and adjust the *.bset files accordingly?

-- 
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.