New source layout.

Sebastian Huber sebastian.huber at embedded-brains.de
Thu Mar 12 14:51:42 UTC 2015


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



More information about the devel mailing list