[PATCH] 5: Use a specific RTEMS tools version

[Chris Johns]

On 17/04/2018 21:18, Sebastian Huber wrote:
> On 17/04/18 12:12, Chris Johns wrote:
>> On 17/4/18 6:49 pm, Sebastian Huber wrote:
>>> On 17/04/18 10:30, Chris Johns wrote:
>>>> On 17/04/2018 18:21, Sebastian Huber wrote:
>>>>> Download via HTTPS RTEMS file server.
>>>>>
>>>>> Close 3241.
>>>> Can you please explain why this solves the issue in the ticket? I do not see
>>>> how
>>>> they relate.
>>> This solves the ticket since git is no longer involved.
>>>
>>>> There can be issues with a sequence of git commands if you are switching
>>>> branches. This can be resolved by improving the sequence used.
>>>>
>>>>> ---
>>>>>    rtems/config/tools/rtems-tools-5-1.cfg | 28 ++++++++++++++++++++++++++--
>>>>>    1 file changed, 26 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> b/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> index 6efc4e3..e0178f0 100644
>>>>> --- a/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> +++ b/rtems/config/tools/rtems-tools-5-1.cfg
>>>>> @@ -7,9 +7,33 @@
>>>>>    #
>>>>>    %if %{rsb_released}
>>>>>     %define rtems_tools_version %{rsb_version}
>>>>> +%else
>>>>> + %define rtems_tools_version ec419a05ee52869a7d5b8712ea8e7a7d74fde096
>>>>>    %endif
>>>> Sorry, this is not the right place for this sort of detail. Version details
>>>> need
>>>> to be in the release defaults or overridden in a an arch specific file.
>>> Sorry, I didn't understand the logic for the rtems_tools_version definition at
>>> all. Why is it dependent on rsb_released?
>> If the RSB is released the RTEMS ftp server is used for downloads and the
>> version is the RTEMS release verson. The RTEMS tools do not have a separate
>> release cycle from RTEMS and use the same version numbers.
>>
>>>> Why this version?
>>> It is the latest commit. So, just the thing that would have been picked by the
>>> current RSB.
>>>
>>> The use of a random HEAD is a major problem from my point of view. It makes the
>>> RSB outcome build time dependent and irreproducible.
>> Releases are matched. I do not follow how this resolves any dependence issue
>> that may appear such as the dl06 and rtems-ld.
> 
> For the latest test suite you need an up to date rtems-ld. If you built the
> tools with RSB 703532cb04c6990fb21e97cb7347a16e9df11108 two months ago, then it
> will not work. If you build with RSB 703532cb04c6990fb21e97cb7347a16e9df11108
> today, then everything is fine. This is a serious defect from my point of view.

How is this any different from all the newlib changes you made? To me it is the
same.

Lets not get to too tangled up here it is development. I clearly stated in the
cover email a tools update was needed and in future I will send a single
specific email to the list to say an update is needed.

>>
>>>> I do not follow or understand the purpose of the change and with a lack of
>>>> specific detail it appears to solve a local problem. It may appear to solve the
>>>> problem because it side steps an issue related to switching branches.
>>> There are some reports on the mailing list related to the rtems-tools download
>>> via git. It has at least two problems:
>>>
>>> 1. It fails sporadically.
>> The real issue in the way git is being sequenced should be fix.
>>
>>> 2. You need internet access during the build.
>> If you updated RTEMS and have disconnected and not updated the RSB with a new
>> hash version downloaded from your home ftp area you have stuffed anyway.
>>
> 
> You should be able to
> 
> ../source-builder/sb-set-builder --dry-run --with-download ...
> 
> and then disconnect from the internet to build the tools.
> 

The ability to create an archive directory is something I would welcome. I side
step around it in the release scripts at the moment but this functionality
should be moved into the RBS. It will happen when I find the time.

Chris