Re: [Xenomai-core] Re: Oops, I broke something

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]