Build Linux: FAILED 5/bsps/atsamv on x86_64-linux-gnu (rtems-libbsd-v816a2f912f414f39467a6be901a96159f806c01d-x86_64-linux-gnu-1)

[Chris Johns]

On 2020-04-07 23:36, Sebastian Huber wrote:
> On 07/04/2020 15:31, Sebastian Huber wrote:
> 
>> On 07/04/2020 15:26, Joel Sherrill wrote:
>>
>>>     > ... The README says "Not all variants are tested" but I cannot see
>>>     > what has been tested? When you are new to a BSP a valid list of
>>>     what
>>>     > works is important.
>>>     The BSP runs on the evaluation board with default options.
>>>
>>>
>>> But it doesn't build to completion? Why would someone assume a build that
>>> fails produces a working set of exes?
>> I didn't claim that the libbsd build system is perfect. The libbsd 
>> works fine if you have a board with enough RAM. The evaluation board 
>> has only 2MiB of SDRAM. This is simply not enough for the standard tests.
> This BSP and the libbsd build system are not good enough right now to 
> add this BSP to an RSB build set.

I agree the build system is lacking but I do not see that as the key 
issue that has been uncovered. The main issue is the addition of 
"special" feature options deep in RTEMS at the BSP level, i.e. 
--enable-chip. Doing this in a specific BSP may let this BSP be 
functional for its users but it is outside the view of the ecosystem and 
as a result the RSB does not have the machinery present to manage that 
option. It might be possible I have not checked. It is really important 
we all make sure BSPs and build options are managed in an agreed 
consistent way so this situation is avoided.

> I should have tested this before I added it. 

I am pleased this has happened. I prefer to know of issues and problems 
ahead of time. I will be using this BSP as a test BSP for any new build 
system with the RSB's vertical stack building.

> This was a mistake.

I do not agree. It has exposed some limitations in what we have and what 
we are doing and this is a good thing.

Chris