Jan Kiszka wrote:
Philippe Gerum wrote:

Gilles Chanteperdrix wrote:

Philippe Gerum wrote:
> Jan Kiszka wrote:
> > But this raised the question to me again if we really need the
> > prefix for all the skin headers /from within xenomai/. Why not
doing the
> > same linking dance for the other skins as well? Or do you also
> > that user include <xenomai/native/task.h> instead of just
>  > We need this for building from within the kernel. Other options
would  > require to either alter the Xenomai source tree adding
symlinks there,  > pollute linux/include with symlinks to reach the
individual Xeno  > components, or refer to some external tree that
eventually redirects to  > the Xenomai tree, which is not acceptable
in any case.

Maybe we could add EXTRA_CFLAGS=-I$(TOPDIR)/include/xenomai to every
xenomai kernel makefile

Yes, I would preferably merge that instead of playing with symlinks.

and to the cflags returned by xeno-config for

kernel-space applications ?

There no such support in xeno-config anymore. Kernel module flags and
dependencies now exclusively belong to the kernel build system;
xeno-config is only relevant for building user-space apps.

Actually, my concerns only targeted the userspace applications, more
precisely those few being built inside the xeno tree. External user apps
can still use the standard, non-prefixed headers. Thus my idea was to
unify the includes for those in-tree applications so that users who are
taking them as reference only see the standard way.

Ack, but this is a matter of general consistency. Now that the issue is raised and that we need to address it, it's better if we don't have to fiddle with exception cases uselessly, so using the proper include directives for both internal/external cases is the best way to go; provided it works, but it should.

External kernel applications and drivers can and should catch this
prefix by adding <linuxsrc>/include/xenomai to their makefiles.




Reply via email to