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