New source layout.

[Amar Takhar]

On 2015-03-07 09:44 +0100, Dominik Taborsky wrote:
> 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.

Great to hear input from new users, thank you!


> > 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?

This has to do with how we have the includes in source.  For instance all source 
will be moved to a full-path style include. eg:

  #include <rtems/public.h>
  #include <rtems/bsp/public.h>

For private it would simply be:

  #include <private.h>
  #include <sys/private.h>

Private APIs can include public but not the other way around.  Using this method 
keeps the build easy as all we need is -Iinclude and nothing more to have 
everything work.  When installed only the include/rtems dir is copied.


> > 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.

Yes that is exactly what it is.


> > - 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?

Only private APIs will lack the 'rtems/' prefix.  Both the RTEMS source, BSP or 
any 3rd part software can use it.  BSPs will only have headers in the public 
space eg <rtems/...>


Amar.