On Thu, Mar 12, 2015 at 10:08 AM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > > 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. > There shouldn't be any BSP includes in target-independent code. Do you know of some?
> The user visible level view should not change. > Agreed. > >>> 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
