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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to