bare bsps configurations to test

[ccj at acm.org (Chris Johns)]

joel at oarcorp.com wrote:
> 
> Both Ralf and David have found problems recently for configurations I do
> not build because there are not BSPs in the tree which trip the code.
> I have some hooks in my test script now to recognize some special bare
> bsps.  I have only used them to test the bare bsp configuration stuff and
> do not regularly build them.
> 
> What I am considering is adding more configurations to my full build set.
> I hope these would be bare BSP configurations which do not correspond to
> any of the BSPs.  For example, I do not think there is a point in building
> a bare cpu32 since the gen68360 supports everything enabled.  On the other
> hand, there are a lot of CPU families and models for which the networking
> code is not compiled.
> 

... and C++. For example not all target processors currently support
exceptions.

>
> Suggestions appreciated for a list of CPU models/cflags which need to be
> test-compiled as bare bsps.  It may end up that the best thing is simply
> for me to define bare bsp configurations for every CPU model and take the
> hit on the build time.
> 

:-)

>
> Once the BSPs are split out from the main source tree and all non-BSP
> specific code is multilib'ed, I do not think we will have this problem any
> more.
> 
> Comments and suggestions appreciated.
> 

Please remember the bare BSP does not perform a link. It does test
processor flags, kernel compiles, and tools, which is more than
currently done. I think this is worth while.

-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj at acm.org    mailto:cjohns at plessey.com.au