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

[Sebastian Huber]

On 08/04/2020 07:14, Sebastian Huber wrote:

> On 08/04/2020 00:59, Chris Johns wrote:
>
>>> 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 think now is the wrong time to discuss this because the way BSPs are 
> configured will change with the new build system.
>
> The header files of this BSP support 27 chip variants: same70j19, 
> same70j20, same70j21, same70n19, same70n20, same70n21, same70q19, 
> same70q20, same70q21, sams70j19, sams70j20, sams70j21, sams70n19, 
> sams70n20, sams70n21, sams70q19, sams70q20, sams70q21, samv71j19, 
> samv71j20, samv71j21, samv71n19, samv71n20, samv71n21, samv71q19, 
> samv71q20, and samv71q21. What would be your alternative to a BSP option?
>
For the new STM32H7 BSP I used a similar approach, see attached file.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200408/09190534/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RTEMS-BUILD-BSP-ARM-STM32H7-OPTVARIANT.yml
Type: application/x-yaml
Size: 1006 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200408/09190534/attachment.bin>