New source layout.

[Amar Takhar]

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.


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

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


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

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.

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.


Amar.