[rtems-source-builder commit] 4.12: Update to use Newlib 2.5.0.20170228

[Chris Johns]

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 <sebastian.huber at embedded-brains.de>
>>> 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