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