Move libbsp/libchip to top of tree

Chris Johns chrisj at rtems.org
Wed Mar 28 20:45:10 UTC 2018


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



More information about the devel mailing list