Newlib Update for RTEMS 4.12
Hello, I updated the RSB to use the Newlib 2.5.0.20170228 snapshot. All users of the RTEMS master are encouraged to update their tool chains. This tool set (Binutils, GCC, Newlib) is the final one for the RTEMS 4.12 release from my point of view. We should get now the RTEMS master ready for the release. -- 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Newlib Update for RTEMS 4.12
On 01/03/2017 23:37, Sebastian Huber wrote: I updated the RSB to use the Newlib 2.5.0.20170228 snapshot. All users of the RTEMS master are encouraged to update their tool chains. This tool set (Binutils, GCC, Newlib) is the final one for the RTEMS 4.12 release from my point of view. We should get now the RTEMS master ready for the release. The 4.12 tools are broken on FreeBSD 11.0: https://sourceware.org/bugzilla/show_bug.cgi?id=21206 This is a blocker for a release. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] sb: Bail out only if hash definitions conflict
[ correct list this time ]
On 01/03/2017 23:33, Sebastian Huber wrote:
Module:rtems-source-builder
Branch:master
Commit:4f72b95e60eedca772994f740a1fd0c973608632
Changeset:
http://git.rtems.org/rtems-source-builder/commit/?id=4f72b95e60eedca772994f740a1fd0c973608632
Author:Sebastian Huber
Date: Wed Mar 1 08:18:07 2017 +0100
Can all future commits to the RSB please be posted to the devel list for
review? This is changes to packages and changes to the code. Thanks.
sb: Bail out only if hash definitions conflict
This patch is wrong and should raise an exception if it is an error.
---
source-builder/sb/sources.py | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/source-builder/sb/sources.py b/source-builder/sb/sources.py
index fb6d819..967becc 100644
--- a/source-builder/sb/sources.py
+++ b/source-builder/sb/sources.py
@@ -97,13 +97,17 @@ def hash(args, macros, error):
return
_map = 'hashes'
_file = macros.expand(args[1])
-if _file in macros.map_keys(_map):
-error('hash already set: %s' % (args[1]))
-return
This looks wrong (I know it is existing :)) ...
-macros.create_map(_map)
-macros.set_write_map(_map)
-macros.define(_file, '%s %s' % (args[0], args[2]))
-macros.unset_write_map()
+new_value = '%s %s' % (args[0], args[2])
+existing_value = get_hash(_file, macros)
+if existing_value is not None:
+if existing_value != new_value:
+error('conflicting hash definitions for: %s' % (args[1]))
+return
... and the same with this ...
+else:
+macros.create_map(_map)
+macros.set_write_map(_map)
+macros.define(_file, new_value)
+macros.unset_write_map()
return None
... cause None is returned.
Chris
___
vc mailing list
v...@rtems.org
http://lists.rtems.org/mailman/listinfo/vc
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] 4.12: Update to use Newlib 2.5.0.20170228
On 01/03/2017 23:33, Sebastian Huber wrote: Module:rtems-source-builder Branch:master Commit:4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Changeset: http://git.rtems.org/rtems-source-builder/commit/?id=4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Author:Sebastian Huber Date: Wed Mar 1 07:30:37 2017 +0100 4.12: Update to use Newlib 2.5.0.20170228 Please do not make structural changes and configuration changes in the same patch. They need to be separate patches. I do not like hashes being collected into a single file, there is no common information that needs to be shared. Why has this change be made? Please revert the change, split the patch and post for review. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-source-builder commit] sb: Bail out only if hash definitions conflict
On 02/03/17 00:11, Chris Johns wrote:
[ correct list this time ]
On 01/03/2017 23:33, Sebastian Huber wrote:
Module:rtems-source-builder
Branch:master
Commit:4f72b95e60eedca772994f740a1fd0c973608632
Changeset:
http://git.rtems.org/rtems-source-builder/commit/?id=4f72b95e60eedca772994f740a1fd0c973608632
Author:Sebastian Huber
Date: Wed Mar 1 08:18:07 2017 +0100
Can all future commits to the RSB please be posted to the devel list
for review? This is changes to packages and changes to the code. Thanks.
Ok.
sb: Bail out only if hash definitions conflict
This patch is wrong and should raise an exception if it is an error.
I didn't change the error handling. All errors in this file call the
error() function. The is no "raise" in this file.
---
source-builder/sb/sources.py | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/source-builder/sb/sources.py b/source-builder/sb/sources.py
index fb6d819..967becc 100644
--- a/source-builder/sb/sources.py
+++ b/source-builder/sb/sources.py
@@ -97,13 +97,17 @@ def hash(args, macros, error):
return
_map = 'hashes'
_file = macros.expand(args[1])
-if _file in macros.map_keys(_map):
-error('hash already set: %s' % (args[1]))
-return
This looks wrong (I know it is existing :)) ...
-macros.create_map(_map)
-macros.set_write_map(_map)
-macros.define(_file, '%s %s' % (args[0], args[2]))
-macros.unset_write_map()
+new_value = '%s %s' % (args[0], args[2])
+existing_value = get_hash(_file, macros)
+if existing_value is not None:
+if existing_value != new_value:
+error('conflicting hash definitions for: %s' % (args[1]))
+return
... and the same with this ...
+else:
+macros.create_map(_map)
+macros.set_write_map(_map)
+macros.define(_file, new_value)
+macros.unset_write_map()
return None
... cause None is returned.
Yes, just like before.
--
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
Re: [rtems-source-builder commit] 4.12: Update to use Newlib 2.5.0.20170228
On 02/03/17 00:12, Chris Johns wrote: On 01/03/2017 23:33, Sebastian Huber wrote: Module:rtems-source-builder Branch:master Commit:4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Changeset: http://git.rtems.org/rtems-source-builder/commit/?id=4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Author:Sebastian Huber Date: Wed Mar 1 07:30:37 2017 +0100 4.12: Update to use Newlib 2.5.0.20170228 Please do not make structural changes and configuration changes in the same patch. They need to be separate patches. The patch affects only the RTEMS 4.12 tool set. I do not like hashes being collected into a single file, there is no common information that needs to be shared. Why has this change be made? I do not like copy and paste. Why should we scatter the hashes throughout the configuration files multiple times? Please revert the change, split the patch and post for review. I didn't break anything as far as I know. In case something is still wrong I prefer to fix individually. -- 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
Re: Newlib Update for RTEMS 4.12
On 01/03/17 23:57, Chris Johns wrote: On 01/03/2017 23:37, Sebastian Huber wrote: I updated the RSB to use the Newlib 2.5.0.20170228 snapshot. All users of the RTEMS master are encouraged to update their tool chains. This tool set (Binutils, GCC, Newlib) is the final one for the RTEMS 4.12 release from my point of view. We should get now the RTEMS master ready for the release. The 4.12 tools are broken on FreeBSD 11.0: https://sourceware.org/bugzilla/show_bug.cgi?id=21206 Who will fix this problem? What happens if this is not fixed in one month or so? This is a blocker for a release. Please add a ticket for things that block the release. -- 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
Re: [rtems-source-builder commit] 4.12: Update to use Newlib 2.5.0.20170228
On 02/03/2017 17:33, Sebastian Huber wrote: On 02/03/17 00:12, Chris Johns wrote: On 01/03/2017 23:33, Sebastian Huber wrote: Module:rtems-source-builder Branch:master Commit:4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Changeset: http://git.rtems.org/rtems-source-builder/commit/?id=4c5eb8969451c4ea0997b3caa98bfe80fe15da69 Author:Sebastian Huber Date: Wed Mar 1 07:30:37 2017 +0100 4.12: Update to use Newlib 2.5.0.20170228 Please do not make structural changes and configuration changes in the same patch. They need to be separate patches. The patch affects only the RTEMS 4.12 tool set. I do not like hashes being collected into a single file, there is no common information that needs to be shared. Why has this change be made? I do not like copy and paste. I have no problem in this case. The configurations should be self contained and built vertically from a common base of basic information. For example rtems-base.bset has the RTEMS version, target, a package name and the RTEMS URLs. There is a GCC message which should move. Why should we scatter the hashes throughout the configuration files multiple times? The way this change has been is done is an abuse of the layering. The change brings configuration specific details into all RTEMS packages and this is not how the RSB was designed. The configurations have being linked laterally and this is something I did not want to see happen. It creates the potential for crosstalk. Specific information for a configuration should be locale to that file. This type flattening of the layers is not done else where in the RSB and I do not want to see if else where either. If a configuration is varying because of a single parameter we should look at why is happening and discuss if a better way can be found to manage it. If you want a hash or group of hashes to shared, for example binutils then make a specific file and only include where it is needed. Please remove the change for a common hashes file. Thank you. Please revert the change, split the patch and post for review. I didn't break anything as far as I know. In case something is still wrong I prefer to fix individually. It is up to you how you remove this, it would look better in the history to have this separated out. Please do not make me revert the change. I do not wish to do this. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Newlib Update for RTEMS 4.12
On 02/03/2017 17:38, Sebastian Huber wrote: On 01/03/17 23:57, Chris Johns wrote: On 01/03/2017 23:37, Sebastian Huber wrote: I updated the RSB to use the Newlib 2.5.0.20170228 snapshot. All users of the RTEMS master are encouraged to update their tool chains. This tool set (Binutils, GCC, Newlib) is the final one for the RTEMS 4.12 release from my point of view. We should get now the RTEMS master ready for the release. The 4.12 tools are broken on FreeBSD 11.0: https://sourceware.org/bugzilla/show_bug.cgi?id=21206 Who will fix this problem? No idea. It is complicated and deep in autoconf. What happens if this is not fixed in one month or so? I do not know. I have taken a look and it seems gdb is getting gnulib to using a C compiler for its configure tests and gnulib generates header files that are included in GDB however GDB is now a C++ program. I tried setting CPP outside the top level configure however this breaks the part of binutils GDB builds and uses. This is a blocker for a release. Please add a ticket for things that block the release. Sure. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
