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

Tue Jan 30 23:01:49 UTC 2018

On 30/01/2018 17:42, Sebastian Huber wrote:
> 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
> 

Thanks for the link and for posting for review. I missed this.

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

Yes and that is normally fine.

> 
>>
>> 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 think this was just a mix up. I was only partially concentrating and _I_
missed the patch for review.

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

I understand.

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

Yes, this is a pain overtime.

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

Both approaches have advantages and disadvantages. I currently cannot see an
optimal solution.

The advantage for your approach checked into git is a single place to change a
version of a tool and you could even argue the tools file is not needed to save
a file. It assumes the various packages will build for all archs and hosts and
if this does not happen it becomes awkward to handle. The disadvantage I see is
the way it changes the layering and ownership of the definition and so you could
argue there is a case to remove the rtems/tools directory. Also this approach
currently requires more work to figure out that a version is.

The previous approach was about "recipes" where a tools file was "the" recipe
for a specific package and the bset files call up that package. It follows the
model of a version matrix where each row is an arch and each column is a version
of RTEMS. I cannot us being able to move away from this model. The disadvantage
is the need to create a new tools file for each release and to update the bset
files or default file.

I am OK with some orphaned files on master as things can move. I often need to
switch versions to play with newer build errors on some hosts.

I still tend to favour the versions files with out the RSB release number, the
'-1' at the end.

Again, I do apologise over any confusion.

Chris