[rtems-source-builder commit] 4.12: Update to use Newlib 2.5.0.20170228
Chris Johns
chrisj at rtems.org
Thu Mar 2 07:11:26 UTC 2017
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
More information about the devel
mailing list