Re: [PATCH] Use a hash file for GCC only
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
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
On 03/03/2017 02:37, Gedare Bloom wrote: On Thu, Mar 2, 2017 at 10:26 AM, Sebastian Huberwrote: 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
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 Huberwrote: > --- > 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
On Thu, Mar 2, 2017 at 10:26 AM, Sebastian Huberwrote: > 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
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