New source layout.

[Chris Johns]

On 13/03/2015 11:48 am, Amar Takhar wrote:
> 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 sis is not a CPU it is a BSP. The dependence is bsp to cpu and not 
the other way around and that path says to me the sis is a type of sparc 
cpu. I can understand '-Iinclude/cpu/sparc/leon3'. Is all the cpu 
independent parts placed under the same include tree as the bsp parts ?

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

This is same as needing the correct defines to be present to get the 
correct source tree. For example the cpu and bsp define both need to be 
present and correct to work and this then needs to be exported to a user.

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

The cpu is the simple case. How does this translate to all the BSP and 
the variants ? A file with 140+ checks seems like a source hot spot and 
trouble.

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

Understood.

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

The rtems-config is a nice tool for users but it is not mandatory. We 
need to consider and document what is being used.

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

We currently install each BSP into a separate tree under the $PREFIX. I 
feel this is still the correct approach. The rtems.waf support handles 
building a single application with more than one installed BSP in this 
configuration. Joining bsps this way means the version of RTEMS for each 
BSP installed is automatically linked for the life of the user's 
project. My experience is they may need to vary and it could be related 
to other factors such as tools effecting RTEMS versions.

Chris