On Thu, Mar 12, 2015 at 9:51 AM, Amar Takhar <a...@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 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. > 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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
