New source layout.

[Joel Sherrill]

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.

The user visible level view should not change.


>> 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