[Xenomai] Qt - Xenomai compatibility problem

[Xenomai] Qt - Xenomai compatibility problem

[George Pontis]

I took a snapshot from git of the current Xenomai code and put it in the hands of the software
developers. They reported that Qt would not build after patching with Xenomai. The problem was that
Qt uses "signals" as a keyword, and that conflicts with the function prototype for rt_task_notify
under xenomai/native:


int rt_task_notify(RT_TASK *task, rt_sigset_t signals);


Although this is not a Xenomai problem, it might save some users the annoyance if the name "signals"
could change.

George

Re: [Xenomai] Qt - Xenomai compatibility problem

[Leopold Palomo-Avellaneda]

A Dimarts, 30 d'abril de 2013, George Pontis va escriure:
> I took a snapshot from git of the current Xenomai code and put it in the 
hands of the software
> developers. They reported that Qt would not build after patching with 
Xenomai. The problem was that
> Qt uses "signals" as a keyword, and that conflicts with the function 
prototype for rt_task_notify
> under xenomai/native:
> 
> 
> int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> 
> 
> Although this is not a Xenomai problem, it might save some users the 
annoyance if the name "signals"
> could change.

I'm not a C++ expert, but to solve this you must encapsulate all the Xenomai 
calls of your software in a namespace. After that, I think that you could use 
the signal word without problem of collision with another signal word.

Regards,

Leopold

-- 
--
Linux User 152692
Catalonia

Re: [Xenomai] Qt - Xenomai compatibility problem

[George Pontis]

> -----Original Message-----
> From: Leopold Palomo-Avellaneda [mailto:leo@alaxarxa.net]
> Sent: Thursday, May 02, 2013 1:37 AM
> To: xenomai@xenomai.org
> Cc: George Pontis
> Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
> 
> A Dimarts, 30 d'abril de 2013, George Pontis va escriure:
> > I took a snapshot from git of the current Xenomai code and put it in the
> hands of the software
> > developers. They reported that Qt would not build after patching with
> Xenomai. The problem was that
> > Qt uses "signals" as a keyword, and that conflicts with the function
> prototype for rt_task_notify
> > under xenomai/native:
> >
> >
> > int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> >
> >
> > Although this is not a Xenomai problem, it might save some users the
> annoyance if the name "signals"
> > could change.
> 
> I'm not a C++ expert, but to solve this you must encapsulate all the Xenomai
> calls of your software in a namespace. After that, I think that you could use
> the signal word without problem of collision with another signal word.
> 
> Regards,
> 
> Leopold

That that won't work because Qt defines the keyword "signals" using #define,
which is handled by the preprocessor.  The preprocessor ignores namespaces
so namespaces wouldn't help in this case.

Geo.

Re: [Xenomai] Qt - Xenomai compatibility problem

[Leopold Palomo-Avellaneda]

A Divendres, 3 de maig de 2013, George Pontis va escriure:
> > -----Original Message-----
> > From: Leopold Palomo-Avellaneda [mailto:leo@alaxarxa.net]
> > Sent: Thursday, May 02, 2013 1:37 AM
> > To: xenomai@xenomai.org
> > Cc: George Pontis
> > Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
> > 
> > A Dimarts, 30 d'abril de 2013, George Pontis va escriure:
> > > I took a snapshot from git of the current Xenomai code and put it in the
> > hands of the software
> > > developers. They reported that Qt would not build after patching with
> > Xenomai. The problem was that
> > > Qt uses "signals" as a keyword, and that conflicts with the function
> > prototype for rt_task_notify
> > > under xenomai/native:
> > >
> > >
> > > int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> > >
> > >
> > > Although this is not a Xenomai problem, it might save some users the
> > annoyance if the name "signals"
> > > could change.
> > 
> > I'm not a C++ expert, but to solve this you must encapsulate all the 
Xenomai
> > calls of your software in a namespace. After that, I think that you could 
use
> > the signal word without problem of collision with another signal word.
> > 
> > Regards,
> > 
> > Leopold
> 
> That that won't work because Qt defines the keyword "signals" using #define,
> which is handled by the preprocessor.  The preprocessor ignores namespaces
> so namespaces wouldn't help in this case.
> 
oops,

thanks for the info. I didn't know that. I could only say that it could not be 
a good idea to make a Qt program with realtime, IMHO. Quoting Jan Kiszka from 
another mail in the list, talking about a program written in Java:

>Writing some non-RT configuration and monitoring front-end in Java is
>fine, but the actual control task is better done in C (or C++ if you
>like). The RT process containing the control task could then have a
>another thread, low priority, that does the non-RT communication with
>the front-end via TCP and transfers any parameter updates to the RT task
>(lock-free or synchronized with a compatible locking mechanism). That's
>the standard design pattern for real-time control applications.

in my opinion this could be applied to a Qt program.

Otherwise, good info about the namespaces and preprocessors.

Regards,

Leopold
-- 
--
Linux User 152692
Catalonia

Re: [Xenomai] Qt - Xenomai compatibility problem

[Gilles Chanteperdrix]

On 04/30/2013 10:50 PM, George Pontis wrote:

> I took a snapshot from git of the current Xenomai code and put it in the hands of the software
> developers. They reported that Qt would not build after patching with Xenomai. The problem was that
> Qt uses "signals" as a keyword, and that conflicts with the function prototype for rt_task_notify
> under xenomai/native:
> 
> 
> int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> 
> 
> Although this is not a Xenomai problem, it might save some users the annoyance if the name "signals"
> could change.


Have you tried the obvious fix?

-- 
                                                                Gilles.

Re: [Xenomai] Qt - Xenomai compatibility problem

[George Pontis]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Friday, May 03, 2013 11:11 AM
> To: George Pontis
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
> 
> On 04/30/2013 10:50 PM, George Pontis wrote:
> 
> > I took a snapshot from git of the current Xenomai code and put it in the hands of the
> software
> > developers. They reported that Qt would not build after patching with Xenomai. The problem
> was that
> > Qt uses "signals" as a keyword, and that conflicts with the function prototype for
> rt_task_notify
> > under xenomai/native:
> >
> >
> > int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> >
> >
> > Although this is not a Xenomai problem, it might save some users the annoyance if the name
> "signals"
> > could change.
> 
> 
> Have you tried the obvious fix?
> 
> --
>                                                                 Gilles.


Yes, to us the obvious fix was to edit the function prototype in the include file
and change "signals" to "_signals".

George

Re: [Xenomai] Qt - Xenomai compatibility problem

[Gilles Chanteperdrix]

On 05/03/2013 08:14 PM, George Pontis wrote:

>> -----Original Message-----
>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Sent: Friday, May 03, 2013 11:11 AM
>> To: George Pontis
>> Cc: xenomai@xenomai.org
>> Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
>>
>> On 04/30/2013 10:50 PM, George Pontis wrote:
>>
>>> I took a snapshot from git of the current Xenomai code and put it in the hands of the
>> software
>>> developers. They reported that Qt would not build after patching with Xenomai. The problem
>> was that
>>> Qt uses "signals" as a keyword, and that conflicts with the function prototype for
>> rt_task_notify
>>> under xenomai/native:
>>>
>>>
>>> int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
>>>
>>>
>>> Although this is not a Xenomai problem, it might save some users the annoyance if the name
>> "signals"
>>> could change.
>>
>>
>> Have you tried the obvious fix?
>>
>> --
>>                                                                 Gilles.
> 
> 
> Yes, to us the obvious fix was to edit the function prototype in the include file
> and change "signals" to "_signals".


And there are no other changes to make to get Xenomai headers included
with qt headers?

-- 
                                                                Gilles.

Re: [Xenomai] Qt - Xenomai compatibility problem

[George Pontis]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Friday, May 03, 2013 11:20 AM
> To: George Pontis
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
> 
> On 05/03/2013 08:14 PM, George Pontis wrote:
> 
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> >> Sent: Friday, May 03, 2013 11:11 AM
> >> To: George Pontis
> >> Cc: xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Qt - Xenomai compatibility problem
> >>
> >> On 04/30/2013 10:50 PM, George Pontis wrote:
> >>
> >>> I took a snapshot from git of the current Xenomai code and put it in the hands of the
> >> software
> >>> developers. They reported that Qt would not build after patching with Xenomai. The problem
> >> was that
> >>> Qt uses "signals" as a keyword, and that conflicts with the function prototype for
> >> rt_task_notify
> >>> under xenomai/native:
> >>>
> >>>
> >>> int rt_task_notify(RT_TASK *task, rt_sigset_t signals);
> >>>
> >>>
> >>> Although this is not a Xenomai problem, it might save some users the annoyance if the name
> >> "signals"
> >>> could change.
> >>
> >>
> >> Have you tried the obvious fix?
> >>
> >> --
> >>                                                                 Gilles.
> >
> >
> > Yes, to us the obvious fix was to edit the function prototype in the include file
> > and change "signals" to "_signals".
> 
> 
> And there are no other changes to make to get Xenomai headers included
> with qt headers?
> 
> --
>                                                                 Gilles.


That was the only change that we needed for our environment. We only use the Posix and native skins. I grep'ed
the include files and found psos+/psos.h and nucleus/thread.h also use "signals". 

Geo.