On 13/03/2015 1:51 am, Sebastian Huber wrote:
----- Amar Takhar <a...@rtems.org> schrieb:
On 2015-03-12 09:45 -0400, Gedare Bloom wrote:
This doesn't work in supposedly CPU-independent source code files.
Let's take percpu.h as an example. We need to include it in
<rtems/score/thread.h> -- the main header for thread scheduling that
is included by virtually every source file in the supercore. We can't
include the CPU-dependent headers here, unless we use the CPP #if-elif
cascase as mentioned by Sebastian.
The eventual goal is everything would be distilled to a single header per arch
that would have to be included in your application source. Right now that is
not possible and we do use the if-elif solution right now in the waf build as a
stopgap.
I am strongly opposed to such a change. The application should not know on
which architecture or BSP it runs.
A single header file per cpu makes no sense. In fact I would like to split up
the cpu.h into two parts. One the is required by rtems.h and one for the rest.
Header files should be self-contained. See also
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Self_contained_Headers.
Forcing users of header files to include other header files in a particular
order before the inclusion exposes implementation details and this is very bad.
I really don't know what the problem is with one -I/path/to/cpukit, one
-I/path/to/cpu, and one -I/path/to/bsp. This is much better than a file with
global knowledge in terms of the #if #elif cascade.
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.
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.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
