New source layout.

Amar Takhar amar at rtems.org
Fri Mar 13 00:48:05 UTC 2015


On 2015-03-13 11:36 +1100, Chris Johns wrote:
> There is complexity in terms of what a user sees which we need to address.
> 
> I also have no problem with more than one -I when building RTEMS and 
> feel we have too. I cannot see a suitable way around this.
> 
> This means we might end up with:
> 
>   include/api
>   include/internal
>   include/cpu/<arch>
>   include/bsp/<bsp>
> 
> and a suitable compiler command to bring this all together.

I would be OK with this as long as we don't endup with:

#include <bsp.h>
-Iinclude/cpu/sparc/sis/

The whole purpose of explicit paths it to avoid picking up the wrong header 
file which has already happened to me more than once.

I understand now -- with your explanation what Sebastian was trying to say.  I 
didn't consider the situation where a user writes an app that works across many 
BSPs.

We can compromise by having a *single* header that includes the correct header 
by architecture.  This means we would have

#include <rtems/rtems.h>
-Iinclude -D__rtems__sparc__

rtems.h would have:
#if __rtems__sparc__
#include <rtems/sparc/rtems.h>
#elif...

This would include all the files appropriate for that architecture without any 
if chains.

These files should not have to change much if at all once first created if 
they're changing often we're doing something wrong.

I would still need to investigate if this is a viable solution though.  I'm not 
sure what's involved.

> What does the post 'waf install' tree look like ?
> 
> It would be nice for a user to only need a single -I. We have discussed 
> percpu and <rtems/score/thread.h> and that all makes sense, so I would 
> like to extend this to the user's build system and consider what effects 
> adding these multiple -I's has to that. Smaller and simpler compiler 
> command lines are better for users. What we currently have is madness 
> with spec files.

Well, rtems-config hides these issues now so users don't have to deal with it.  
Having a single -I is nice but then we run into the situation where a user may 
want to have more than 1 architecture installed.  For instance if they're 
developing an app for all architectures they can test using waf and have it 
build 1 bsp of their choosing per arch in the same working directory.

This works right now.


Amar.



More information about the devel mailing list