Sorry about forgetting the ticket. My main point was do we want to do this before branching or not?
There are a lot of tickets outstanding and we need to start working to an end. On Wed, Mar 28, 2018, 3:45 PM Chris Johns <chr...@rtems.org> wrote: > On 29/03/2018 00:26, Gedare Bloom wrote: > > 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? > >> > > Yes, I missed the include directory when I looked. Sorry for the noise. > > >>> > >>>> 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 > >> > > Sorry, I had forgotten we did. > > >>> 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. > >> > > I should clean my tree of removed directories. > > >>> - 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. > >> > Maybe not, I did not look into the code to see what it depended on. > > Where to ... bsps/shared/ ? > > >>> - c/src/bsp.pc.in => bsps/ > >>> - c/src/libchip => devices (not sure about this) > >> > >> > >> This should move to bsps/shared/dev/* > > Sure. > > >> > >>> - 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.) > > > > Agreed, I had forgotten what happens with moves in git. Shame cause the > name is > not relevant any more. > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
