New source layout.

[Amar Takhar]

On 2015-03-13 13:57 +0100, Sebastian Huber wrote:
> 
> 
> 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.

I worded that poorly this is what I was trying to say.  Right now it works the 
way you want.  In the future it will still work this way but there won't be a 
requirement for -Iinclude/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 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.

OK that's good to know, the 'fix' branch is only changes I made to get RTEMS to 
build w/tests nothing has been run.  I have no idea any of those changes are 
correct or not.


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

OK.  This isn't the first example of the problem though.  I'll have to go back 
and see if I can pull out the others from older repositories.  Unfortunately many 
of them landed as commits by Chris when I was doing the original waf build.  It 
was a year long project to unwind everything.


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

I know they aren't related.  I brought it up because using -B in any situation 
is not an option, neither are spec files I wanted to make this clear.


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

The one file per architecture as I noted in a previous email would be hidden 
from the user using a single if chain.


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

We we will have to agree to disagree on the first point.  For the second part: 
yes the step must be removed.


> Information hiding is a key principle in software engineering.

But not software testing.  If you hide information it makes software difficult 
to test as the testable areas become less obvious.  If you hide interfaces 
behind layers of includes what ends up happening is the first API only gets 
tested.  This is the principal behind flattening: You are able to test all 
functions at every layer from the 'top down' or 'bottom up'.


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

This hasn't happened due to the preinclude step there are hundreds of cross 
dependencies that are hidden.


Amar.