On Wed, Mar 28, 2018 at 1:16 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > On 28/03/18 02:11, Chris Johns wrote: >> >> 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. > > > I thought the structure is clear now. Everything BSP related should go to > "bsps" with public headers in "include" subdirectories. This is the same > structure we have in "cpukit". Where do you see duplicated names? > >> >>> 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. > > > I thought we already have a plan. > > https://devel.rtems.org/ticket/3285 > >> 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 > > > We already have a bsps/include? > >> - c/src/lib/libbsp/. => bsps/ > > > Yes, but please with a common structure for all BSPs as defined by > > https://devel.rtems.org/ticket/3285 > >> - c/src/ada => ada > > > There is no c/src/ada. > >> - c/src/support/verison.c => cpukit/sapi/version-string.c > > > Is the RTEMS_BSP define available in cpukit? If yes, then this is a bug. > >> - c/src/bsp.pc.in => bsps/ >> - c/src/libchip => devices (not sure about this) > > > This should move to bsps/shared/dev/* > >> - Rename cpukit because *kit means nothing >> - cpukit => kernel > > > No, please lets not do this. This makes searching the commit history more > difficult just for the sake of some cosmetic naming change. Removing the > preinstall step or getting rid of three directory levels is a different > story. > +6 (In concurrence with Sebastian.)
Gedare > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
