New source layout.

[Chris Johns]

On 13/03/2015 1:51 am, Sebastian Huber wrote:
>
> ----- Amar Takhar <amar at rtems.org> schrieb:
>> 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.
>
> I am strongly opposed to such a change.  The application should not know on which architecture or BSP it runs.
>
> A single header file per cpu makes no sense.  In fact I would like to split up the cpu.h into two parts.  One the is required by rtems.h and one for the rest.
>
> Header files should be self-contained.  See also http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers.  Forcing users of header files to include other header files in a particular order before the inclusion exposes implementation details and this is very bad.
>
> I really don't know what the problem is with one -I/path/to/cpukit, one -I/path/to/cpu, and one -I/path/to/bsp.  This is much better than a file with global knowledge in terms of the #if #elif cascade.
>

There is complexity in terms of what a user sees which we need to address.

I also have no problem with more than one -I when building RTEMS and 
feel we have too. I cannot see a suitable way around this.

This means we might end up with:

  include/api
  include/internal
  include/cpu/<arch>
  include/bsp/<bsp>

and a suitable compiler command to bring this all together.

What does the post 'waf install' tree look like ?

It would be nice for a user to only need a single -I. We have discussed 
percpu and <rtems/score/thread.h> and that all makes sense, so I would 
like to extend this to the user's build system and consider what effects 
adding these multiple -I's has to that. Smaller and simpler compiler 
command lines are better for users. What we currently have is madness 
with spec files.

Chris