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.cudm...@nasa.gov <mailto:alan.p.cudm...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
