On 8/03/2015 12:51 pm, Amar Takhar wrote:
Please ignore the previous include layout the correct is below copied from another email in this thread:
Thanks for starting this thread. Reorganising the source tree in RTEMS is long over due.
I assume this is all post 4.11 and based on the up coming waf build system. It makes sense to move RTEMS a major revision number which would make 4.11 the last 4.x series release.
---- I just noticed the layout I gave above was wrong! Gedare sent me an email (he could not email the list directly from his device). I had a typo in the original one and also didn't copy the new one I made. Sigh. I have reordered and fixed it below with some examples: The directories should be: include/rtems/ - Public API include/ - Private API
With the public API as a subtree of the private does this mean there is only a single include path to the include tree given to the compiler ?
Does private mean the headers are not installed so are more 'internal' than 'private' ? To me internal means they can used internally to RTEMS but cannot be installed or referenced by public headers while private makes me wonder what I can use and should not use.
With testing will we have in tree testing and installed testing, ie a test to check no header leakage ?
include/arch/ - Private architecture specific include/bsp/ - Common BSP files include/bsp/<arch> - Architecture specific
Does this mean all <arch> references are explicit and not using compiler include path tricks ?
This allows for: #include <rtems/header.h> - Public API #include <header.h> - Private API #include <arch/header.h> - Private architecture specific #include <bsp/header.h> - Common BSP file #include <bsp/arch/header.h> - BSP architecture specific Where 'arch' is replaceable by any architecture. RTEMS has 1,500 headers we will have no issues filling these directories up. There are 3,258 headers in the waf build. 1,700 of these will be removed after we fix the references in the source -- a project for down the road.
Getting these files back under control is fantastic. Again many thanks. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
