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.hu...@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.hu...@embedded-brains.de
PGP     : Public key available on request.

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

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to