Move libbsp/libchip to top of tree

Chris Johns chrisj at rtems.org
Wed Mar 28 00:11:06 UTC 2018


On 28/03/2018 07:09, Joel Sherrill wrote:
> 
> On Tue, Mar 27, 2018 at 2:56 PM, Cudmore, Alan P. (GSFC-5820)
> <alan.p.cudmore at nasa.gov <mailto:alan.p.cudmore at nasa.gov>> wrote:
> 
>     I like the idea, but to me it would be confusing to have bsp and bspkit at
>     the top level, each having nearly the same directories. (but certainly less
>     confusing than before)____
> 
>     At the risk of introducing more work, would it make sense to have bspkit
>     with inc and src subdirectories?
> 

Alan, this is a good point and highlights a weakness in the current positioning
of the bsp includes. In this context it would seem to be a mistake to have the
includes under 'bsps' because it leads to a duplicated name of some type at the
top level. A 'bsps/include' directory would make the BSPs consistent with
'cpukit/include' plus it is a sensible path.

> Yeah. I forgot to mention that we would have to address that. Having a directory
> that is "pure installed .h" files is desirable and we would have to address having
> two similarly named directories.

I think a tree plan needs to be made before we move any more code about to avoid
moving twice. As a starting point for a discussion here is a list:

- Removing 'c' moving all contents to other parts of the tree
  - bsps/. => bsps/include
  - c/src/lib/libbsp/. => bsps/
  - c/src/ada => ada
  - c/src/support/verison.c => cpukit/sapi/version-string.c
  - c/src/bsp.pc.in => bsps/
  - c/src/libchip => devices (not sure about this)
- Rename cpukit because *kit means nothing
  - cpukit => kernel

Chris



More information about the devel mailing list