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.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 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
