On 18/11/2017 19:15, Sebastian Huber wrote: > It would be nice if we are able to back port fixes from the next master > (6.0.0) to RTEMS 5.1 easily. I guess RTEMS 5.1 could be a long term release > since all the work for SMP which resulted in a massive re-write of the > operating system internals stabilizes now.
This is a good idea but is it possible at this point in time? It will happen at some point and it will be a change that will have this issue. My current guess doing this change would require a sequence of patches to fix headers that cause problems in some BSPs (see VME.h below as an example) and then generation of a script to do a `git mv`. We can chat off-list about the headers that have an issue. > For the new build system we have to get rid of the preinstall anyway, so we > maybe we should move the header files now and already remove the preinstall > step in the current build system. File moves make back ports difficult. I > think we only need six header include directories: > > cpukit/include > cpukit/libnetworking/include > cpukit/score/cpu/$arch/include > c/src/include > c/src/lib/libbsp/$arch/include > c/src/lib/libbsp/$arch/$bsp/include I thought the approach was a single top level include tree. I think it would be better to move the headers only once. What about: include cpukit/libnetworking/include bsps/$arch/$bsp/include Should cpukit/libnetworking become network/legacy ? The only downside for this layout is a BSP would get a copy of arch, libcpu etc header files they are not using. I do not mind this because the code should not be using -I compiler tricks, we should have the source and header paths cleanly mapped. We would also need to consider the various $(PROJECT_LIB) files that are installed. These are things like bsp_specs and linker command files. Do these move? I think they should. > The header file move in the BSP area is a bit of work. There are 3 basic types of files being managed via the preinstall.am files. They are directories, pre-install files and temporary install files (internal libraries). All these would need to be resolved to fix this bug. The generated preinstalls has 90 instances of the `$(PROJECT_INCLUDE)/bsp` directory create, 83 instances of installing `$(PROJECT_INCLUDE)/bsp.h` and 174 instances of the word `linkcmds` in an installed file name. There are 2650 preinstall instances in the preinstall.am files and then you have the complexity of 3 separate VME.h files in BSPs, 2 each of vmeTsi148.h and vmeTsi148DMA.h. I have no idea if these files are the same or different. These would need to be audited and changed with the corresponding changes to the source. I suspect the current install model, ie make install, for the final resting place for headers would need to be reviewed and considered. Would these be a single tree for common headers per $PREFIX or per BSP copy? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
