[Xenomai-core] Oops, I broke something

[Xenomai-core] Oops, I broke something

[Jan Kiszka]

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

Hi Philippe,

my RTDM header "optimisation" broke the compilation of
testsuite/latency. I need an extra link for the userspace compilation
inside xeno now. Please apply this patch

--- configure.in        (Revision 372)
+++ configure.in        (Arbeitskopie)
@@ -348,6 +348,8 @@

 base=include
 AC_CONFIG_LINKS([src/include/xenomai:$base])
+base=rtdm
+AC_CONFIG_LINKS([src/include/$base:include/$base])
 base=asm-$XENO_TARGET_ARCH
 AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base])
 base=asm-generic

and run bootstrap. Sorry.

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>?

Jan

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

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

[Philippe Gerum]

Jan Kiszka wrote:
> Hi Philippe,
> 
> my RTDM header "optimisation" broke the compilation of
> testsuite/latency. I need an extra link for the userspace compilation
> inside xeno now. Please apply this patch
> 
> --- configure.in        (Revision 372)
> +++ configure.in        (Arbeitskopie)
> @@ -348,6 +348,8 @@
> 
>  base=include
>  AC_CONFIG_LINKS([src/include/xenomai:$base])
> +base=rtdm
> +AC_CONFIG_LINKS([src/include/$base:include/$base])
>  base=asm-$XENO_TARGET_ARCH
>  AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base])
>  base=asm-generic
> 
> and run bootstrap. Sorry.
> 
> 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.

-- 

Philippe.

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

[Philippe Gerum]

Jan Kiszka wrote:
> Hi Philippe,
> 
> my RTDM header "optimisation" broke the compilation of
> testsuite/latency. I need an extra link for the userspace compilation
> inside xeno now. Please apply this patch
> 
> --- configure.in        (Revision 372)
> +++ configure.in        (Arbeitskopie)
> @@ -348,6 +348,8 @@
> 
>  base=include
>  AC_CONFIG_LINKS([src/include/xenomai:$base])
> +base=rtdm
> +AC_CONFIG_LINKS([src/include/$base:include/$base])
>  base=asm-$XENO_TARGET_ARCH
>  AC_CONFIG_LINKS([src/include/asm/xenomai:include/$base])
>  base=asm-generic
> 
> and run bootstrap. Sorry.
> 
> 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>?
>

Nope, people writing apps should not have to handle our internal issues, 
asking them to prefix with xenomai/ is not an option.


> Jan


-- 

Philippe.

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

[Gilles Chanteperdrix]

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 and to the cflags returned by xeno-config for
kernel-space applications ?

-- 


					    Gilles Chanteperdrix.

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

[Philippe Gerum]

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.

-- 

Philippe.

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

[Philippe Gerum]

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

While checking the 2.4 builds for ppc and x86, I stumbled upon cases 
where we do need this fix right now (e.g. benchmark and 16550A drivers). 
So I will handle this global change right after -rc2 is out.

-- 

Philippe.

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

[Jan Kiszka]

[-- 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 --]

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

[Philippe Gerum]

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
>>>"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.

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.
> 
> Jan


-- 

Philippe.