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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
