----- Amar Takhar <a...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
