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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
