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