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 >> "xenomai" >> > > 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 >> prefer >> > > that user include <xenomai/native/task.h> instead of just >> <native/task.h>? >> > > 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. External kernel applications and drivers can and should catch this prefix by adding <linuxsrc>/include/xenomai to their makefiles. Jan
signature.asc
Description: OpenPGP digital signature
