Move libbsp/libchip to top of tree

Gedare Bloom gedare at rtems.org
Wed Mar 28 13:26:45 UTC 2018


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?
>
>>
>>> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel



More information about the devel mailing list