New source layout.

[Sebastian Huber]

On 13/03/15 01:48, 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/

This is exactly what we need.

>
> 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 never had the problem that the wrong header files were picked up and I 
don't remember that a RTEMS users had such a problem in the past. To use 
an installed BSP was actually quite easy. You only need one -B switch, 
the right -m flags and the evil spec file.

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

Trading a -I switch for a -D switch is a bad choice. With a -I switch 
you get access to an arbitrary amount of header files. With the -D 
switch you need additional pre-processor stuff in an arbitrary amount of 
header files with copy and paste involved. There is also no such thing 
as "that architecture". We have sub-architectures as well, e.g. ARMv7-M 
is completely different to ARMv4 in terms of the exception model. A 
central header file including everything for one architecture prevents 
information hiding and leads to unnecessary dependencies.

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

We should try to reduce the size of the installed RTEMS tree, and this 
will also lead to three include paths, one for the cpukit, one for the 
CPU and one for the BSP.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.