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
