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 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200408/329f3030/attachment-0001.html>