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