New source layout.

[Gedare Bloom]

On Thu, Mar 12, 2015 at 10:08 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On March 12, 2015 8:56:36 AM CDT, Gedare Bloom <gedare at rtems.org> wrote:
>>On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar <amar at rtems.org> wrote:
>>> On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
>>>> This doesn't work in supposedly CPU-independent source code files.
>>>>
>>>> Let's take percpu.h as an example. We need to include it in
>>>> <rtems/score/thread.h> -- the main header for thread scheduling that
>>>> is included by virtually every source file in the supercore. We
>>can't
>>>> include the CPU-dependent headers here, unless we use the CPP
>>#if-elif
>>>> cascase as mentioned by Sebastian.
>>>
>>> The eventual goal is everything would be distilled to a single header
>>per arch
>>> that would have to be included in your application source.  Right now
>>that is
>>> not possible and we do use the if-elif solution right now in the waf
>>build as a
>>> stopgap.
>>>
>>Relying on the application to provide the header means coupling the
>>RTEMS build to the application build. This is an as-yet-undiscussed
>>direction that should be elaborated in a separate thread.
>
> I am opposed to anything that works against modularity and increases cohesion. Some of the architecture .h files may be able to be combined but they all should not be.
>
> I am also strongly opposed to making architecture visible to the application source code. We have worked hard to prevent this.
>
>>I might be happy with some CPP magic to hide the if-elif cascade if
>>that is plausible.
>>RTEMS_INCLUDE_CPU_SPECIFIC(cpu.h)
>>or some such.
>
> This is ok for port files but may be unworkable for bsp related ones. It would at least take a two level cascade to be managable for per bsp files.
>
There shouldn't be any BSP includes in target-independent code. Do you
know of some?

> The user visible level view should not change.
>
Agreed.

>
>>> I've asked Chris to better explain this he understands the issues
>>from an RTEMS
>>> perspective better than I do.  He also knows what the eventual goal
>>of the
>>> header move is.
>>>
>>OK.
>>
>>> To be clear: the intermediary period is already solved in the waf
>>build nothing
>>> will have to change.  As we change / 'unwind' the headers we'll
>>modify the
>>> source.  This is going to be a drawn out process.  The nice thing is
>>any changes
>>> we make in this regard is verifiable by using hashes of the resulting
>>objects.
>>>
>>>
>>> Amar.
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>_______________________________________________
>>devel mailing list
>>devel at rtems.org
>>http://lists.rtems.org/mailman/listinfo/devel
>
> --joel