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