New BSP source structure

[Gedare Bloom]

On Wed, Jan 31, 2018 at 6:57 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
>
> On 31/01/18 00:12, Chris Johns wrote:
>>
>> On 31/01/2018 01:16, Gedare Bloom wrote:
>>>
>>> On Tue, Jan 30, 2018 at 1:44 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>>>
>>>> On 29/01/18 21:45, Chris Johns wrote:
>>>>>
>>>>> On 29/1/18 6:32 pm, Sebastian Huber wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> now that all BSP header files are in
>>>>>>
>>>>>> * bsps/include
>>>>>>
>>>>>> * bsps/@RTEMS_CPU@/include
>>>>>>
>>>>>> * bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@/include
>>>>>>
>>>>>> we should also move the BSP sources to this new directory tree. How do
>>>>>> we
>>>>>> want
>>>>>> to organize the BSP sources in bsps/@RTEMS_CPU@/@RTEMS_BSP_FAMILY@?
>>>>>>
>>>>> Yes this is a good thing to do.
>>>>
>>>>
>>>> The question is this: should it go into the 5.1 release? I guess it
>>>> needs
>>>> three to six months to get this done.
>>>>
>>> I think our guiding philosophy moving forward is to cut a release with
>>> any major change? We should not hold up a release for a second major
>>> change like this, even if it is related.
>>>
>> Backporting fixes going to be OK?
>
>
> I had a brief look into the build system stuff under c. It seems
> c/src/configure is the main target code build driver. Looks like a
> considerable amount (more that two person weeks) of work to move the stuff.
>
In terms of back-porting, it may be best to refactor the existing BSP
structure into the common way described below for this release, at
least for the "major" BSPs, but keeping them under c/src/libbsp. This
way, back-port fixes should be a matter of mapping the relocated
files, but the directory structures they were relocated to should not
be too different.

-Gedare