New source layout.

[Dominik Taborsky]

I am a newbie to RTEMS, but this sounds great. The current layout is 
very confusing to newcomers. Kudos to you, Amar!
Please, see my notes further on.

On 03/07/2015 02:20 AM, Amar Takhar wrote:
> The following is a proposal for a new source layout that will be included in the
> new 'waf' build system.  The current layout is a product of years of laying and
> requirements for the auto* build system.  Since we are no longer restricted by
> this it makes sense to take the time and give RTEMS a more sensible source
> layout.
>
> rtems/bsp/* exists to carry common bsp files.  I don't know why it makes sense
> to have score/* then cpu/* with separate architectures.  Even if the purpose is
> different does it make sense to have two completely separate areas with
> architecture hierarchies?  There may have been a reason to do this before is
> there one now?
>
> There are some interdependencies between the common BSP files (bsp.h).  I can
> hack around this for now using waf until we can break this interdependency by
> moving to public APIs.
>
> Note: the reason for rtems/bsp/* existing is to unhook rtems/ and bsp/ 100%.
> This means you can develop a BSP with only librtems installed on your system and
> nothing else.  We will also support a build that does not build any BSP code.
> It will also allow us to split our tests correctly as well.
>
> I will propose a 1:1 mapping of all source and header files from current -> new
> location for approval once we have the general layout completed.  I would like
> to avoid renaming the source files themselves until after we have moved and
> verified everything builds OK.  Renaming the files in-dir is a trivial
> operation and can be verified using a hash of the resulting libraries.
>
>
> include locations
> ~~~~~~~~~~~~~~~~~
> include/rtems/include/             - Private API
> include/rtems/include/rtems/       - Public API
> include/rtems/bsp/include/         - Common BSP files
> include/rtems/bsp/include/<arch>   - Architecture specific

Just one question here: Why have the public API hidden in a subdir of 
private APIs? Shouldn't this be the other way around?

>
>
> rtems
> ~~~~
> rtems/lib/ada/          [c/src/ada]
> rtems/lib/block
> rtems/lib/csupport
> rtems/lib/fs
> rtems/lib/misc
> rtems/lib/networking
> rtems/lib/rpc
> rtems/lib/z
> rtems/lib/qos
> rtems/lib/md
> rtems/lib/gnat
> rtems/lib/i2c
> rtems/lib/rtems++       [c/src/librtems++]
> rtems/classic           [cpukit/rtems]

Again, I'm a newbie, but what is 'classic' in RTEMS?
The old 'cpukit' sounds like it's a bunch of tools to work with the CPU. 
The new 'classic' sounds like it's the good old RTEMS from history.

> rtems/posix
> rtems/sapi
> rtems/server/ftpd
> rtems/server/mghttpd
> rtems/server/pppd
> rtems/score
>
> The following need to be discussed in detail as they will end up split into multiple locations:
> rtems/bsp/chip/         [c/src/libchip]
> rtems/bsp/shared/<arch> [c/src/lib/libcpu]
>
> Note: c/src/support has been killed.
>
>
> bsp (contents of c/src/lib/libbsp, actual BSP source)
> ~~~
> bsp/<arch>/
> bsp/<arch>/<bsp>/
> bsp/<arch>/<bsp>/include <-installable BSP headers.
>
>
> installed locations
> ~~~~~~~~~~~~~~~~~~
> include/rtems/                  - Public API
> include/rtems/bsp/              - Common BSP files
> include/rtems/bsp/<arch>/       - Architecture specific
> include/rtems/bsp/<arch/<bsp>/  - BSP specific
>
>
> changes to source
> ~~~~~~~~~~~~~~~~
> - All RTEMS source will use #include <rtems/header.h> for public API

You actually mean "<rtems/header.h>" and not "<rtems/rtems.h>" or even 
just "<rtems.h>"? When you say "RTEMS source" and "public API", do you 
mean the RTEMS source code or 3rd party source that builds with RTEMS?


Other than that, good job, Amar. :)

Dominik