Move libbsp/libchip to top of tree

Joel Sherrill joel at rtems.org
Wed Mar 28 21:15:59 UTC 2018


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 <chrisj at rtems.org> wrote:

> On 29/03/2018 00:26, Gedare Bloom wrote:
> > On Wed, Mar 28, 2018 at 1:16 AM, Sebastian Huber
> > <sebastian.huber at 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.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.
> >>
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180328/04d5daa1/attachment-0002.html>


More information about the devel mailing list