On March 12, 2015 8:56:36 AM CDT, Gedare Bloom <ged...@rtems.org> wrote: >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 am opposed to anything that works against modularity and increases cohesion. Some of the architecture .h files may be able to be combined but they all should not be. I am also strongly opposed to making architecture visible to the application source code. We have worked hard to prevent this. >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. This is ok for port files but may be unworkable for bsp related ones. It would at least take a two level cascade to be managable for per bsp files. The user visible level view should not change. >> 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 --joel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
