New source layout.

[Sebastian Huber]

On 13/03/15 13:38, Amar Takhar wrote:
> On 2015-03-13 09:45 +0100, Sebastian Huber wrote:
>>> #include <bsp.h>
>>> -Iinclude/cpu/sparc/sis/
>> This is exactly what we need.
> I agree we need this right now but it's not a requirement for the future.

For me this is a requirement for the future. A lot of applications use 
<bsp.h> to create for example the network configuration. Unless we have 
a better alternative we should not break this.

>
>
>>> 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.
> https://git.rtems.org/amar/waf.git/commit/?h=fix&id=08e5b8cce3a140135f11f9498de371637e4ec7af

This change is wrong. The first include must be <pthread.h> to get the 
prototype for |pthread_cleanup_pop() for example and ensure that 
<pthread.h> is self-contained.

|
>
> Since the right -I dir wasn't added it picked up pthread.h from the compiler.

It picked up the right file.

>   
> It failed in a very strange way that was really annoying to debug at first it
> wasn't clear that it was picking up the wrong header file since the only error
> was "pthread.h:..."  versus "rtems/posix/pthread.h:...".
>
> This isn't the first time this has happened to me over the last 4 years it's
> wasted hours of my time because I didn't have the right -I lines.  Since I've
> changed the behaviour I've been able to expose API bleeding and have not had
> this issue.
>
> -B is a GCC-only switch.  spec files are also gcc-only both of these have been
> eliminated in the waf build -- the spec files still exist actually but are
> generated as part of the build process so we can support any compiler.

The spec files have nothing to do with the includes. You can replace the 
-B with a -Iinclude for the includes.

>
>
>> 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.
> We would have exactly 1 ifchain in 1 file (rtems.h).  This would include the
> correct file per-arch.  What copy and paste are you referring to?  I'm trying to
> understand.

I don't want one header file per architecture. For example <rtems.h> has 
no reason to see the interrupt stack frame structure and other 
implementation details.

>
> Information hiding is exactly what I'm trying to avoid and is a large part of
> the reason why we're in the situation we have right now.  It's far too easy to
> 'modify the build' to get code working.

The pre-installed header files are not that bad. What is bad is that all 
the header files are scattered in the source tree. We have to get rid of 
the pre-install step.

Information hiding is a key principle in software engineering.

>
> To be clear: I agree with you that complicating the user experience is bad.  I
> also agree that complicating the RTEMS build is bad.  I don't believe we should
> compromise on the user experience we can still keep it simple.  The RTEMS build
> itself will have to be more exposed to avoid API bleeding and hiding complexity
> with no added benefit.  If it's complex then we need to figure out how to make
> it less complex by design of the source not the build.
>
>
>> 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.
> With the way things are now that's impossible because noone has any idea what
> headers are required on a per-bsp basis.  We need all of them, period.  I'm
> really trying to solve that issue by 'flattening' what we've done in order to
> get all of this cleaned up.
>
> Once it's flattened I'll be able to add builds in BuildBot to test for API
> bleeding from installed BSPs.  The test would be:
>
>   waf build --bsp=sparc/sis --prefix=/tmp/path
>   waf install
>   rm -rf build
>   gcc -c sometest.c --cflags `rtems-config --cflags --bsp=sparc/sis`
>   ld .. `rtems-config --ldflags -bsp=sparc/sis`
>
> We can't even do this right now as it's impossible to know what bsps require
> which files.  We've also found examples of BSPs being depending on headers from
> other BSPs.  This happened when I was trying to convert the BSPs to waf I believe
> Chris fixed several of these years ago.

In case a file is used by more than one BSP it must move to a shared 
include directory.

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