Re: [PATCH] Use a hash file for GCC only

2017-03-08 Thread Chris Johns 

On 08/03/2017 17:10, Sebastian Huber wrote:



On 07/03/17 23:24, Chris Johns wrote:

On 03/03/2017 02:23, Gedare Bloom wrote:

In a way, I do like that this shows the different gcc-newlib versions
we use. It might be nice to add a bit of organization to this hashes
file and/or documentation of the procedure for adding/removing
entries.

Maybe it makes more sense to have a separate file for each version
being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
That should make it easier to maintain the hashes.

I'll leave it to Chris to decide if this is a suitable compromise.



This seems to have stalled and I have had to push the change to fix
builds on FreeBSD 11.0 so reverting the change is not possible.

Please apply this patch. We can look at further improvement as future
refactoring work.


After the comments in this thread I sent an alternative patch that
removes the hash file:


I am sorry, I must have missed it.



https://lists.rtems.org/pipermail/devel/2017-March/017102.html

Which one do you like?



This is fine.

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

Re: [PATCH] Use a hash file for GCC only

2017-03-07 Thread Sebastian Huber 



On 07/03/17 23:24, Chris Johns wrote:

On 03/03/2017 02:23, Gedare Bloom wrote:

In a way, I do like that this shows the different gcc-newlib versions
we use. It might be nice to add a bit of organization to this hashes
file and/or documentation of the procedure for adding/removing
entries.

Maybe it makes more sense to have a separate file for each version
being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
That should make it easier to maintain the hashes.

I'll leave it to Chris to decide if this is a suitable compromise.



This seems to have stalled and I have had to push the change to fix 
builds on FreeBSD 11.0 so reverting the change is not possible.


Please apply this patch. We can look at further improvement as future 
refactoring work.


After the comments in this thread I sent an alternative patch that 
removes the hash file:


https://lists.rtems.org/pipermail/devel/2017-March/017102.html

Which one do you like?

--
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: [PATCH] Use a hash file for GCC only

2017-03-02 Thread Chris Johns 

On 03/03/2017 02:37, Gedare Bloom wrote:

On Thu, Mar 2, 2017 at 10:26 AM, Sebastian Huber
 wrote:

On 02/03/17 16:23, Gedare Bloom wrote:


In a way, I do like that this shows the different gcc-newlib versions
we use. It might be nice to add a bit of organization to this hashes
file and/or documentation of the procedure for adding/removing
entries.

Maybe it makes more sense to have a separate file for each version
being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
That should make it easier to maintain the hashes.

I'll leave it to Chris to decide if this is a suitable compromise.



I don't know why this hash stuff caused such an uproar. The hashes are
invariants of the files. If they ever change something is seriously wrong.
Things that never change should be defined exactly once in a system.


It seems that you stumbled over an unwritten design philosophy.


Yes this is true and given the limited doco and time to create it I 
apologize for this not being clearer. I feel reviews will help avoid 
this situation.


This is an architectural change and my experience with the RSB is 
changes like this always end up having 2 side. I have been caught before 
implementing what I thought was a good and spending lots of time 
cleaning it up or fixing side effects. For example hashes was a simple 
addition to add a hash next to the specified file, what could be simpler.



I'm
not picking sides on this, but I do think it is a good idea to
organize the hashes into include files to reduce the copy-paste.


The configurations need to be self contained and adding unrelated 
information in a single place makes it harder to remove and clean up. 
Yes the hashes are invariant as Sebastian points out and adding them is 
easy however removing them is awkward and time consuming when you need 
to determine where they may be used. Removing a configuration needs to 
be simple and specific to the configuration and spreading fingers into 
global lists would not help.



I
also think my suggestion of putting them in version-based files
alleviates the "horizontal integration" concern.


What would you call the hashes file? Is it any different to the actual 
configuration file?


Should we split newlib out from gcc and have the higher level include 
each file to create the pair?


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

Re: [PATCH] Use a hash file for GCC only

2017-03-02 Thread Gedare Bloom 
In a way, I do like that this shows the different gcc-newlib versions
we use. It might be nice to add a bit of organization to this hashes
file and/or documentation of the procedure for adding/removing
entries.

Maybe it makes more sense to have a separate file for each version
being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
That should make it easier to maintain the hashes.

I'll leave it to Chris to decide if this is a suitable compromise.

On Thu, Mar 2, 2017 at 7:20 AM, Sebastian Huber
 wrote:
> ---
>  rtems/config/hash.cfg  | 41 
> --
>  rtems/config/rtems-base.bset   |  2 --
>  rtems/config/tools/hash-gcc.cfg| 33 +
>  .../rtems-gcc-4.8.3-newlib-2.5.0.20170228-1.cfg|  2 ++
>  .../rtems-gcc-4.9.2-newlib-2.5.0.20170228-1.cfg|  2 ++
>  .../rtems-gcc-4.9.3-newlib-2.5.0.20170228-1.cfg|  2 ++
>  .../rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg|  1 +
>  7 files changed, 40 insertions(+), 43 deletions(-)
>  delete mode 100644 rtems/config/hash.cfg
>  create mode 100644 rtems/config/tools/hash-gcc.cfg
>
> diff --git a/rtems/config/hash.cfg b/rtems/config/hash.cfg
> deleted file mode 100644
> index 63f5d8b..000
> --- a/rtems/config/hash.cfg
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -%hash sha512 b6c483b4a98424731e6e44558cb4b9863751fb1b.zip 
> 80fe9603851b5dcad048b488d049341af3abdcb564481efac4a85d6d3aeb6be9c0967e26a62752ab38df7ce9838e91c25c4808459587e9c5472cda07f27c9341
> -%hash sha512 binutils-2.20.1-rtems4.10-20151123.diff 
> ce24ba3e56e7552739c167950a488d80557fdf562dcb527b2e5972c2d18da42a8fd1a47197e54aff0df630d105eb40702f09cad330c193cb8f9309b43b1fb1bc
> -%hash sha512 binutils-2.26-rtems-aarch64-x86_64.patch 
> 2236cc22dda60d5c18a2ab5abc0f44bf487794f7c0899382bf49233e789e1fb34ce28b0f7a85069642f7cc06bd34d7634a441a8d92bf890de57bb89cc398349f
> -%hash sha512 f05996c7c42e6b2781946acbab153a481ce3fd0b.zip 
> eeb44951ff9e23ecaad15607a1cc40699464b1707302cd4105363b862aab19382929917deb4abebedb4637e5a1c30b7c941b1d7d372824452203bda1ed8e5c7d
> -%hash sha512 f7051762470c42ce7f01baa7edeb113d51c7dd72.zip 
> 260d1678007f9a33e438c0fe7c0400750c1524ab5c118689059480e79d3e1ad62f72d9db273dc188f5113d0cadfb81cb75b1b1edc689dd7391fd008430ac797d
> -%hash sha512 gcc-4.8.3-or1k-rtems-29072014.diff 
> 89d622f93e3759d2bec062a7a2c83c29fd3630539db18680f1307ea84d3f64a79f83c30e45ccfc2e7637589ad2a679d61a06c9be041388e910fc05421fc749cc
> -%hash sha512 gcc-4.9.3-or1k.patch 
> d63122c3ab71e867aba323e88e1ec2e937b0fca0e26db6ac2a56550c29a90933506735553079f986d5dd54c1acff5533ac087da8f69acad4f3c1e4d5be73d041
> -%hash sha512 gcc-6.0.1-RC-20160415.tar.bz2 
> 5c03c1a74cc762c2421cd9b5818deca6e6191a19ebe07eaa407e152cd1d4341eed5e15ed9a35d8e372891574d492fb67d0885ce302dcf5d71c89021b0f420c40
> -%hash sha512 gcc-6-20160117.tar.bz2 
> 61d05ad097c640004fad4805b6c407282825d5fcdad11413c47de7178d8f7f2488e2b5f3e354620bca5506b7b7abd464d65db0aea78f89cd63a253e88dd217eb
> -%hash sha512 gcc-6-20160124.tar.bz2 
> ab90e21b13ead10c58bd2ce17abf4ccffc81355f366c99e6bfce883d288198704d3510d447d48217d4a3e233120da20fc6335dce102ba2dc4785b28a745881da
> -%hash sha512 gcc-6-20160228.tar.bz2 
> cc768440bf6b89ad58fb64cf2fd93898929f63cd212cdb54443543135be9e713c409f9e2740531376510cad59172b197cad769df14345834bc1cd17b33976a57
> -%hash sha512 gcc-6-20160327.tar.bz2 
> 0213c44e457585d15ad13fc3a7c665ba78faba0d1685e71cbf0cf32e44523394589ac60c7aea567e29c6f5e18159b446b1b0a7d39e330021c40efd8077aa5ad7
> -%hash sha512 gcc-6-20160526.tar.bz2 
> 8ad457b463432b2cc7fc4c1b7967c2a01909f5fd40d2e7a1f38f8b197859ab2c823b96dfaf36add4177f6f932c7e702cc4ac9201b88375404235fc1a03ef778d
> -%hash sha512 gcc-6-20160609.tar.bz2 
> f9ea9034c0456d350e418a7263cdd02596fdd553f40e9741907436f0df7dbbc5b025ea421c2aece2769ade8e356985c104a37fe6c1bdc51eb61d52257206e0f1
> -%hash sha512 gcc-6-20161110.tar.bz2 
> b75f73950a409658b45a6dc2fcbfe18b38aba53fdd55f509e17637fb0d50464b6636394297fd33a0843684f7ef3eefefd1dcf8f257694ab4f15339ae37c8437e
> -%hash sha512 gcc-6.3.0.tar.bz2 
> 234dd9b1bdc9a9c6e352216a7ef4ccadc6c07f156006a59759c5e0e6a69f0abcdc14630eff11e3826dd6ba5933a8faa43043f3d1d62df6bd5ab1e82862f9bf78
> -%hash sha512 gcc-core-4.3.2-rtems4.9-20090825.diff 
> d326372a756a7289404031eb16dcc51c15259342ea3f8697f23cfa754ee38305d5e6aaeef56c83f11cdd28c85711c430d894a87303ad932b024a17fa4aaa4f63
> -%hash sha512 gcc-core-4.3.2.tar.bz2 
> 7fa7cfd57b3cb37990f41132037666d511a480df28d6d5a0620520501488abad89c7843067188bbe23f0c4d3eb5d113537a6a9375135596b58b3d7a848dc8a39
> -%hash sha512 gcc-core-4.4.7-rtems4.10-20151123.diff 
> 70e5868157fd02f011e66f8fa9dcdc3341deee47ff105d9102a501b6e346c0e635c70600ff0646ea5f28faf8152e806367cf8acb60ff35ac61348af20796c4e4
> -%hash sha512 gdb-6.8a.tar.bz2 
> 5114fe14ab25dc085590acff3a6feb75eb93347e501c634548308c4f51b31416ea23b8e612dfc54da466d3e7471e210d8f7a12ff6c050e9e89920884e5a64008
> -%hash sha512 gdb-6.8-rtems4.9-2009.diff 
>

Re: [PATCH] Use a hash file for GCC only

2017-03-02 Thread Gedare Bloom 
On Thu, Mar 2, 2017 at 10:26 AM, Sebastian Huber
 wrote:
> On 02/03/17 16:23, Gedare Bloom wrote:
>>
>> In a way, I do like that this shows the different gcc-newlib versions
>> we use. It might be nice to add a bit of organization to this hashes
>> file and/or documentation of the procedure for adding/removing
>> entries.
>>
>> Maybe it makes more sense to have a separate file for each version
>> being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
>> That should make it easier to maintain the hashes.
>>
>> I'll leave it to Chris to decide if this is a suitable compromise.
>
>
> I don't know why this hash stuff caused such an uproar. The hashes are
> invariants of the files. If they ever change something is seriously wrong.
> Things that never change should be defined exactly once in a system.
>
It seems that you stumbled over an unwritten design philosophy. I'm
not picking sides on this, but I do think it is a good idea to
organize the hashes into include files to reduce the copy-paste. I
also think my suggestion of putting them in version-based files
alleviates the "horizontal integration" concern.

> --
> 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: [PATCH] Use a hash file for GCC only

2017-03-02 Thread Sebastian Huber 

On 02/03/17 16:23, Gedare Bloom wrote:

In a way, I do like that this shows the different gcc-newlib versions
we use. It might be nice to add a bit of organization to this hashes
file and/or documentation of the procedure for adding/removing
entries.

Maybe it makes more sense to have a separate file for each version
being used, e.g. a gcc-4.8.3 hash file, gcc-4.9.3, gcc-6.0.1, etc?
That should make it easier to maintain the hashes.

I'll leave it to Chris to decide if this is a suitable compromise.


I don't know why this hash stuff caused such an uproar. The hashes are 
invariants of the files. If they ever change something is seriously 
wrong. Things that never change should be defined exactly once in a system.


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

[PATCH] Use a hash file for GCC only

2017-03-02 Thread Sebastian Huber 
---
 rtems/config/hash.cfg  | 41 --
 rtems/config/rtems-base.bset   |  2 --
 rtems/config/tools/hash-gcc.cfg| 33 +
 .../rtems-gcc-4.8.3-newlib-2.5.0.20170228-1.cfg|  2 ++
 .../rtems-gcc-4.9.2-newlib-2.5.0.20170228-1.cfg|  2 ++
 .../rtems-gcc-4.9.3-newlib-2.5.0.20170228-1.cfg|  2 ++
 .../rtems-gcc-6.3.0-newlib-2.5.0.20170228-1.cfg|  1 +
 7 files changed, 40 insertions(+), 43 deletions(-)
 delete mode 100644 rtems/config/hash.cfg
 create mode 100644 rtems/config/tools/hash-gcc.cfg

diff --git a/rtems/config/hash.cfg b/rtems/config/hash.cfg
deleted file mode 100644
index 63f5d8b..000
--- a/rtems/config/hash.cfg
+++ /dev/null
@@ -1,41 +0,0 @@
-%hash sha512 b6c483b4a98424731e6e44558cb4b9863751fb1b.zip 
80fe9603851b5dcad048b488d049341af3abdcb564481efac4a85d6d3aeb6be9c0967e26a62752ab38df7ce9838e91c25c4808459587e9c5472cda07f27c9341
-%hash sha512 binutils-2.20.1-rtems4.10-20151123.diff 
ce24ba3e56e7552739c167950a488d80557fdf562dcb527b2e5972c2d18da42a8fd1a47197e54aff0df630d105eb40702f09cad330c193cb8f9309b43b1fb1bc
-%hash sha512 binutils-2.26-rtems-aarch64-x86_64.patch 
2236cc22dda60d5c18a2ab5abc0f44bf487794f7c0899382bf49233e789e1fb34ce28b0f7a85069642f7cc06bd34d7634a441a8d92bf890de57bb89cc398349f
-%hash sha512 f05996c7c42e6b2781946acbab153a481ce3fd0b.zip 
eeb44951ff9e23ecaad15607a1cc40699464b1707302cd4105363b862aab19382929917deb4abebedb4637e5a1c30b7c941b1d7d372824452203bda1ed8e5c7d
-%hash sha512 f7051762470c42ce7f01baa7edeb113d51c7dd72.zip 
260d1678007f9a33e438c0fe7c0400750c1524ab5c118689059480e79d3e1ad62f72d9db273dc188f5113d0cadfb81cb75b1b1edc689dd7391fd008430ac797d
-%hash sha512 gcc-4.8.3-or1k-rtems-29072014.diff 
89d622f93e3759d2bec062a7a2c83c29fd3630539db18680f1307ea84d3f64a79f83c30e45ccfc2e7637589ad2a679d61a06c9be041388e910fc05421fc749cc
-%hash sha512 gcc-4.9.3-or1k.patch 
d63122c3ab71e867aba323e88e1ec2e937b0fca0e26db6ac2a56550c29a90933506735553079f986d5dd54c1acff5533ac087da8f69acad4f3c1e4d5be73d041
-%hash sha512 gcc-6.0.1-RC-20160415.tar.bz2 
5c03c1a74cc762c2421cd9b5818deca6e6191a19ebe07eaa407e152cd1d4341eed5e15ed9a35d8e372891574d492fb67d0885ce302dcf5d71c89021b0f420c40
-%hash sha512 gcc-6-20160117.tar.bz2 
61d05ad097c640004fad4805b6c407282825d5fcdad11413c47de7178d8f7f2488e2b5f3e354620bca5506b7b7abd464d65db0aea78f89cd63a253e88dd217eb
-%hash sha512 gcc-6-20160124.tar.bz2 
ab90e21b13ead10c58bd2ce17abf4ccffc81355f366c99e6bfce883d288198704d3510d447d48217d4a3e233120da20fc6335dce102ba2dc4785b28a745881da
-%hash sha512 gcc-6-20160228.tar.bz2 
cc768440bf6b89ad58fb64cf2fd93898929f63cd212cdb54443543135be9e713c409f9e2740531376510cad59172b197cad769df14345834bc1cd17b33976a57
-%hash sha512 gcc-6-20160327.tar.bz2 
0213c44e457585d15ad13fc3a7c665ba78faba0d1685e71cbf0cf32e44523394589ac60c7aea567e29c6f5e18159b446b1b0a7d39e330021c40efd8077aa5ad7
-%hash sha512 gcc-6-20160526.tar.bz2 
8ad457b463432b2cc7fc4c1b7967c2a01909f5fd40d2e7a1f38f8b197859ab2c823b96dfaf36add4177f6f932c7e702cc4ac9201b88375404235fc1a03ef778d
-%hash sha512 gcc-6-20160609.tar.bz2 
f9ea9034c0456d350e418a7263cdd02596fdd553f40e9741907436f0df7dbbc5b025ea421c2aece2769ade8e356985c104a37fe6c1bdc51eb61d52257206e0f1
-%hash sha512 gcc-6-20161110.tar.bz2 
b75f73950a409658b45a6dc2fcbfe18b38aba53fdd55f509e17637fb0d50464b6636394297fd33a0843684f7ef3eefefd1dcf8f257694ab4f15339ae37c8437e
-%hash sha512 gcc-6.3.0.tar.bz2 
234dd9b1bdc9a9c6e352216a7ef4ccadc6c07f156006a59759c5e0e6a69f0abcdc14630eff11e3826dd6ba5933a8faa43043f3d1d62df6bd5ab1e82862f9bf78
-%hash sha512 gcc-core-4.3.2-rtems4.9-20090825.diff 
d326372a756a7289404031eb16dcc51c15259342ea3f8697f23cfa754ee38305d5e6aaeef56c83f11cdd28c85711c430d894a87303ad932b024a17fa4aaa4f63
-%hash sha512 gcc-core-4.3.2.tar.bz2 
7fa7cfd57b3cb37990f41132037666d511a480df28d6d5a0620520501488abad89c7843067188bbe23f0c4d3eb5d113537a6a9375135596b58b3d7a848dc8a39
-%hash sha512 gcc-core-4.4.7-rtems4.10-20151123.diff 
70e5868157fd02f011e66f8fa9dcdc3341deee47ff105d9102a501b6e346c0e635c70600ff0646ea5f28faf8152e806367cf8acb60ff35ac61348af20796c4e4
-%hash sha512 gdb-6.8a.tar.bz2 
5114fe14ab25dc085590acff3a6feb75eb93347e501c634548308c4f51b31416ea23b8e612dfc54da466d3e7471e210d8f7a12ff6c050e9e89920884e5a64008
-%hash sha512 gdb-6.8-rtems4.9-2009.diff 
2e6eb2bdeac4bba7c2fcaf701399148fc5de82dfa81e02f5a20654afe5aad77d6fd0edbc31965107f2fe9a43738938d79a313836267ad69dc8509fcbf691
-%hash sha512 gdb-7.11-or1k.patch 
e0c0171b62650e1dcc58a846322d3f2899c0b2196eec7ba1b600a012931e125a5dbb21e19bde79b0786781feca6b19054b307ffd57010c4d5c63c408d2f3144a
-%hash sha512 gdb-7.3.1-rtems4.10-20151123.diff 
2e03f9b01626a1f18c025eecb70350bdd7a29574970fb80edc985d0c5731325a68e42d55fb5d3e23440ea6e384e093269cca79a95d5a4e44a678439977da313f
-%hash sha512 gdb-7.7-or1k-rtems.diff 
a334503fa1159fe4e1eb61c87501a0543da11f202e2b989b105ba8383c45294bad68bd726b810304bc0baad718b9785eeb3054c5d75de6301b942b0a7a31b95a
-%hash sha512 gmp-4.3.2.tar.bz2