[Xenomai] building Xenomai Apps with CMake (RFC)

[Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

Hello,

I went ahead and created a script to add support for Xenomai (3+) to CMake. Its currently sufficient for me,
but I would like to get this in a shape that it is useful and robust enough for most people.
Ultimately it should end up up streamed to CMake (I hope the binutils-specific wrappers aren't a knock-out against adoption).

Mostly this should interest people that want to use CMake, but a few things might need support from the Xenomai distribution.
To be more specific: using precompiled object-files like the boostrap code and its linker wraps and redirections are something I would
like to avoid, or atleast offer an alternative that does not need that much work outside of a "regular build".
For that, having the bootstrap code (configurable or a few variants) installed as sourcecode would help.

Code is uploaded to Github : https://github.com/nolange/cmake_xenomai

Kind regards
Norbert Lange


________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Jan Kiszka]

On 2018-04-03 16:10, Lange Norbert wrote:
> Hello,
> 
> I went ahead and created a script to add support for Xenomai (3+) to CMake. Its currently sufficient for me,
> but I would like to get this in a shape that it is useful and robust enough for most people.
> Ultimately it should end up up streamed to CMake (I hope the binutils-specific wrappers aren't a knock-out against adoption).
> 
> Mostly this should interest people that want to use CMake, but a few things might need support from the Xenomai distribution.
> To be more specific: using precompiled object-files like the boostrap code and its linker wraps and redirections are something I would
> like to avoid, or atleast offer an alternative that does not need that much work outside of a "regular build".
> For that, having the bootstrap code (configurable or a few variants) installed as sourcecode would help.
> 
> Code is uploaded to Github : https://github.com/nolange/cmake_xenomai

Thanks for sharing this. IIRC, we have some Xeommai user in-house as
well who looked into cmake, need to check the status and scope again
(maybe Henning knows more). Could be interesting, indeed.

For my understanding: You need cmake upstream changes to make things
work? Or is this project something that could eventually be carried in
Xenomai upstream, just requiring some cmake version >= X?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

Hello,

 >-----Original Message-----
 >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
 >Sent: Donnerstag, 05. April 2018 16:55
 >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
 >Subject: Re: building Xenomai Apps with CMake (RFC)
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >On 2018-04-03 16:10, Lange Norbert wrote:
 >> Hello,
 >>
 >> I went ahead and created a script to add support for Xenomai (3+) to CMake.
 >Its currently sufficient for me,
 >> but I would like to get this in a shape that it is useful and robust enough for
 >most people.
 >> Ultimately it should end up up streamed to CMake (I hope the binutils-specific
 >wrappers aren't a knock-out against adoption).
 >>
 >> Mostly this should interest people that want to use CMake, but a few things
 >might need support from the Xenomai distribution.
 >> To be more specific: using precompiled object-files like the boostrap code
 >and its linker wraps and redirections are something I would
 >> like to avoid, or atleast offer an alternative that does not need that much
 >work outside of a "regular build".
 >> For that, having the bootstrap code (configurable or a few variants) installed
 >as sourcecode would help.
 >>
 >> Code is uploaded to Github : https://github.com/nolange/cmake_xenomai
 >
 >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
 >well who looked into cmake, need to check the status and scope again
 >(maybe Henning knows more). Could be interesting, indeed.

If I may ask, are you using the "boostraps" from Xenomai or some own init-code?
(that’s currently the biggest headache remaining)

 >
 >For my understanding: You need cmake upstream changes to make things
 >work? Or is this project something that could eventually be carried in
 >Xenomai upstream, just requiring some cmake version >= X?

No strict need to upstream the scripts in either Xenomai or CMake, the files just need to be in the search-path of CMake to be usable (likely doesnt need anything newer than CMake 3.0 but would need to test this).
I value the feedback from both communities, particularly because I don’t use anything but the Posix/Cobalt Skin
and getting it into CMake would be the best thing for maintenance.

Nevertheless it could be really helpful to add a headerfile in the Xenomai distribution, replicating the steps that 'boilerplate/init/bootstrap.c' does,
and allowing to disable parts of the functionality like the main wrapper.
That glue code would ideally be built together with libraries/executables using it (identical flags and such).
Right now the code is mostly duplicated and placed with the CMake Scripts, which is not ideal.

Norbert
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Henning Schild]

Am Thu, 5 Apr 2018 15:54:34 +0000
schrieb Lange Norbert <norbert.lange@andritz.com>:

> Hello,
> 
>  >-----Original Message-----
>  >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
>  >Sent: Donnerstag, 05. April 2018 16:55
>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
>  >Subject: Re: building Xenomai Apps with CMake (RFC)
>  >
>  >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
>  >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
>  >ATTACHMENTS.
>  >
>  >
>  >On 2018-04-03 16:10, Lange Norbert wrote:  
>  >> Hello,
>  >>
>  >> I went ahead and created a script to add support for Xenomai (3+)
>  >> to CMake.  
>  >Its currently sufficient for me,  
>  >> but I would like to get this in a shape that it is useful and
>  >> robust enough for  
>  >most people.  
>  >> Ultimately it should end up up streamed to CMake (I hope the
>  >> binutils-specific  
>  >wrappers aren't a knock-out against adoption).  
>  >>
>  >> Mostly this should interest people that want to use CMake, but a
>  >> few things  
>  >might need support from the Xenomai distribution.  
>  >> To be more specific: using precompiled object-files like the
>  >> boostrap code  
>  >and its linker wraps and redirections are something I would  
>  >> like to avoid, or atleast offer an alternative that does not need
>  >> that much  
>  >work outside of a "regular build".  
>  >> For that, having the bootstrap code (configurable or a few
>  >> variants) installed  
>  >as sourcecode would help.  
>  >>
>  >> Code is uploaded to Github :
>  >> https://github.com/nolange/cmake_xenomai  
>  >
>  >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
>  >well who looked into cmake, need to check the status and scope again
>  >(maybe Henning knows more). Could be interesting, indeed.  
> 
> If I may ask, are you using the "boostraps" from Xenomai or some own
> init-code? (that’s currently the biggest headache remaining)

No, i do not know anyone using CMake with Xenomai, so i would not know
how to deal with bootstrap there.

>  >
>  >For my understanding: You need cmake upstream changes to make things
>  >work? Or is this project something that could eventually be carried
>  >in Xenomai upstream, just requiring some cmake version >= X?  
> 
> No strict need to upstream the scripts in either Xenomai or CMake,
> the files just need to be in the search-path of CMake to be usable
> (likely doesnt need anything newer than CMake 3.0 but would need to
> test this). I value the feedback from both communities, particularly
> because I don’t use anything but the Posix/Cobalt Skin and getting it
> into CMake would be the best thing for maintenance.

It would probably be a good idea to try and mainline it in one of the
two projects. And my guess is that CMake would not really fit and they
might not want such code.

> Nevertheless it could be really helpful to add a headerfile in the
> Xenomai distribution, replicating the steps that
> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts of
> the functionality like the main wrapper. That glue code would ideally
> be built together with libraries/executables using it (identical
> flags and such). Right now the code is mostly duplicated and placed
> with the CMake Scripts, which is not ideal.

I did not fully understand the bootstrap with regard to cmake yet. But
the magic wrapping is not pretty, also in other regards. So patches
that improve that, while actually targeting something like CMake, would
be welcome.

Now regarding CMake itself. Is not one of its main purposes to be
platform independant, that does not seem to be too useful for Xenomai.
And there is a zoo of such build systems out there, what about bazel,
scons, rake ... ? So i guess i am against adding support for any such
thing to xenomai, especially if its OS abstractions do not match --
like it seems to be the case for CMake.

Henning

> Norbert
> ________________________________
> 
> This message and any attachments are solely for the use of the
> intended recipients. They may contain privileged and/or confidential
> information or other information protected from disclosure. If you
> are not an intended recipient, you are hereby notified that you
> received this email in error and that any review, dissemination,
> distribution or copying of this email and any attachment is strictly
> prohibited. If you have received this email in error, please contact
> the sender and delete the message and any attachment from your system.
> 
> ANDRITZ HYDRO GmbH
> 
> 
> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung /
> Corporation
> 
> Firmensitz/ Registered seat: Wien
> 
> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
> 
> Firmenbuchnummer/ Company registration: FN 61833 g
> 
> DVR: 0605077
> 
> UID-Nr.: ATU14756806
> 
> 
> Thank You
> ________________________________

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

 >-----Original Message-----
 >From: Henning Schild [mailto:henning.schild@siemens.com]
 >Sent: Freitag, 06. April 2018 10:47
 >To: Lange Norbert
 >Cc: Jan Kiszka; Xenomai (xenomai@xenomai.org)
 >Subject: Re: building Xenomai Apps with CMake (RFC)
 >
 >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >ATTACHMENTS.
 >
 >
 >Am Thu, 5 Apr 2018 15:54:34 +0000
 >schrieb Lange Norbert <norbert.lange@andritz.com>:
 >
 >> Hello,
 >>
 >>  >-----Original Message-----
 >>  >From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
 >>  >Sent: Donnerstag, 05. April 2018 16:55
 >>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org); Henning Schild
 >>  >Subject: Re: building Xenomai Apps with CMake (RFC)
 >>  >
 >>  >E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
 >>  >EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
 >>  >ATTACHMENTS.
 >>  >
 >>  >
 >>  >On 2018-04-03 16:10, Lange Norbert wrote:
 >>  >> Hello,
 >>  >>
 >>  >> I went ahead and created a script to add support for Xenomai (3+)
 >>  >> to CMake.
 >>  >Its currently sufficient for me,
 >>  >> but I would like to get this in a shape that it is useful and
 >>  >> robust enough for
 >>  >most people.
 >>  >> Ultimately it should end up up streamed to CMake (I hope the
 >>  >> binutils-specific
 >>  >wrappers aren't a knock-out against adoption).
 >>  >>
 >>  >> Mostly this should interest people that want to use CMake, but a
 >>  >> few things
 >>  >might need support from the Xenomai distribution.
 >>  >> To be more specific: using precompiled object-files like the
 >>  >> boostrap code
 >>  >and its linker wraps and redirections are something I would
 >>  >> like to avoid, or atleast offer an alternative that does not need
 >>  >> that much
 >>  >work outside of a "regular build".
 >>  >> For that, having the bootstrap code (configurable or a few
 >>  >> variants) installed
 >>  >as sourcecode would help.
 >>  >>
 >>  >> Code is uploaded to Github :
 >>  >> https://github.com/nolange/cmake_xenomai
 >>  >
 >>  >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
 >>  >well who looked into cmake, need to check the status and scope again
 >>  >(maybe Henning knows more). Could be interesting, indeed.
 >>
 >> If I may ask, are you using the "boostraps" from Xenomai or some own
 >> init-code? (that’s currently the biggest headache remaining)
 >
 >No, i do not know anyone using CMake with Xenomai, so i would not know
 >how to deal with bootstrap there.

This question was not limited to CMake, but I am curious whether the bootstrap magic
from the tools shipping with Xenomai is popular outside of it.

 >
 >>  >
 >>  >For my understanding: You need cmake upstream changes to make things
 >>  >work? Or is this project something that could eventually be carried
 >>  >in Xenomai upstream, just requiring some cmake version >= X?
 >>
 >> No strict need to upstream the scripts in either Xenomai or CMake,
 >> the files just need to be in the search-path of CMake to be usable
 >> (likely doesnt need anything newer than CMake 3.0 but would need to
 >> test this). I value the feedback from both communities, particularly
 >> because I don’t use anything but the Posix/Cobalt Skin and getting it
 >> into CMake would be the best thing for maintenance.
 >
 >It would probably be a good idea to try and mainline it in one of the
 >two projects. And my guess is that CMake would not really fit and they
 >might not want such code.

Well, there are multiple Linux-only modules already (FindLTTngUST, FindX11),
aswell as "non-OS" compilers like IAR.
I doubt they would be happy if I add some bootstrap code for Xenomai though.

https://cmake.org/cmake/help/latest/manual/cmake-modules.7.html

 >
 >> Nevertheless it could be really helpful to add a headerfile in the
 >> Xenomai distribution, replicating the steps that
 >> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts of
 >> the functionality like the main wrapper. That glue code would ideally
 >> be built together with libraries/executables using it (identical
 >> flags and such). Right now the code is mostly duplicated and placed
 >> with the CMake Scripts, which is not ideal.
 >
 >I did not fully understand the bootstrap with regard to cmake yet. But
 >the magic wrapping is not pretty, also in other regards. So patches
 >that improve that, while actually targeting something like CMake, would
 >be welcome.

There is no bootstrap with CMake yet, and I am unsure whether the current
method should be supported at all.
The cost of adding the bootstrap code to a *new* project is low, and even lower
If this would be distributed as header with Xenomai (Again that would not be limited to CMake). You of course
lose the ability to compile sources as-is (which I believe was the motivation)

My plan would be to allow applications/libraries an easy way of creating their own bootstrap code.
2 variants of this:

bootstrap-wrap.c:
#define_ XENOMAI_BOOTSTRAP_DEFINE_MAINWRAPPER
// do more than just fetching the Xenomai-releated arguments
// (like handling --help)
#define _XENOMAI_BOOTSTRAP_PROCESS_ARGV
#include <xenomai/bootstrap-template.h>


bootstrap-dso.c:
#define _XENOMAI_BOOTSTRAP_DSO
#include <xenomai/bootstrap-template.h>

(That would obviously need the xenomai/bootstrap-template.h in Xenomai)

 >
 >Now regarding CMake itself. Is not one of its main purposes to be
 >platform independant, that does not seem to be too useful for Xenomai.
 >And there is a zoo of such build systems out there, what about bazel,
 >scons, rake ... ? So i guess i am against adding support for any such
 >thing to xenomai, especially if its OS abstractions do not match --
 >like it seems to be the case for CMake.

You look at it from the wrong side, your (sub-)project is platform independent,
Xenomai is just one possible target. This transitively works throughout possibly
dependencies - they won't care what platform they are compiled for.

With CMake you can have one application (or its *parts*) developed on/for:
-   Xenomai (Production)
-   Linux (Verification, Unittests)
-   Windows (please don't ask)

And most IDEs support CMake nowadays (detecting include paths + settings, build, etc).

This started as a need to use a flexible build-system,
it ended up being CMake, and it already suffices for our needs.
As a sidenote, it started with building ARM Cortex Firmwares on gcc and IAR,
and software-modules from those projects could now be used as they are
with Xenomai projects.

Google for "FindXenomai" to see that I am hardy the only one with that need.
What I would like is to have a proper solution for Xenomai, and my way of doing that
is to get criticized from people-in-the-know.

 > , what about bazel, scons, rake ... ?

Dunno, not my interest, not my intent to solve every problem in the world.
Adding proper CMake support in a proper place (be it Xenomai or CMake) instead
of using the twentieth home-cooked solution is what I am interested in.

Norbert

________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Leopold Palomo-Avellaneda]

Hi,

On 06/04/18 10:47, Henning Schild wrote:

[...]

>>  >Thanks for sharing this. IIRC, we have some Xeommai user in-house as
>>  >well who looked into cmake, need to check the status and scope again
>>  >(maybe Henning knows more). Could be interesting, indeed.  
>>
>> If I may ask, are you using the "boostraps" from Xenomai or some own
>> init-code? (that’s currently the biggest headache remaining)
> 
> No, i do not know anyone using CMake with Xenomai, so i would not know
> how to deal with bootstrap there.

I use CMake ...

>>  >
>>  >For my understanding: You need cmake upstream changes to make things
>>  >work? Or is this project something that could eventually be carried
>>  >in Xenomai upstream, just requiring some cmake version >= X?  
>>
>> No strict need to upstream the scripts in either Xenomai or CMake,
>> the files just need to be in the search-path of CMake to be usable
>> (likely doesnt need anything newer than CMake 3.0 but would need to
>> test this). I value the feedback from both communities, particularly
>> because I don’t use anything but the Posix/Cobalt Skin and getting it
>> into CMake would be the best thing for maintenance.
> 
> It would probably be a good idea to try and mainline it in one of the
> two projects. And my guess is that CMake would not really fit and they
> might not want such code.
> 
>> Nevertheless it could be really helpful to add a headerfile in the
>> Xenomai distribution, replicating the steps that
>> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts of
>> the functionality like the main wrapper. That glue code would ideally
>> be built together with libraries/executables using it (identical
>> flags and such). Right now the code is mostly duplicated and placed
>> with the CMake Scripts, which is not ideal.
> 
> I did not fully understand the bootstrap with regard to cmake yet. But
> the magic wrapping is not pretty, also in other regards. So patches
> that improve that, while actually targeting something like CMake, would
> be welcome.

Maybe I didn't understood deeply the problem here, but when I switch to Xenomai
-3 I got it.

When you were working with Xenomai-2, and you create your program, then using
xeno-config you could obtain your main information to compile and link.

So, if you want to build your posix program, xeno-config gave you:

$ xeno-config --skin posix --ldflags
-Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers -L/usr/lib/x86_64-linux-gnu
-lpthread_rt -lxenomai -lpthread -lrt

$ xeno-config --skin posix --cflags
-I/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -D__XENO__
-I/usr/include/xenomai/posix


With Xenomai-3, you obtain similar parameters with cflags:

$ xeno-config --skin posix --cflags
-I/usr/include/xenomai/cobalt -I/usr/include/xenomai -g -O2
-fdebug-prefix-map=/build/xenomai-3.0.6+ds2rtnet=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables
-D__COBALT__ -D__COBALT_WRAP__

But, ldflags:

$ xeno-config --skin posix --ldflags
-Wl,--no-as-needed -Wl,@/usr/lib/x86_64-linux-gnu/cobalt.wrappers
-Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
/usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
-L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt -Wl,-z,relro
-Wl,-z,now -Wl,--as-needed   -lfuse -pthread

Here note that to your program you must add and object:
/usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o

that depends on the --auto-init|auto-init-solib|no-auto-init option and could be:

- none (--no-auto-init)
- bootstrap-pic.o (--auto-init-solib)
- bootstrap.o (--auto-init or default)

To me the questions then are:
- The code there could be encapsulated in a header?
- or could be put in a lib?
- only could be done in this way?


Regarding to CMake, I solved this passing this arguments to VARS to cmake. So,
tge FindXenomai was a simple wrapper to xeno-config to obtain the correct values
to build the xeno application.

If my memory doesn't fail it was something that Gilles recommend some years ago.
The best way to build a xenomai application is to use the xeno-config output to
obtain the correct values.

So, my point of view is that you don't have to modify anything from Xenomai to
use it with CMake. Another thing is the bootstrap stuff that maybe it's a bit ugly.


> Now regarding CMake itself. Is not one of its main purposes to be
> platform independant, that does not seem to be too useful for Xenomai.

I don't understand exactly what do you want to say. CMake, from its webpage [1]

"CMake is an open-source, cross-platform family of tools designed to build, test
and package software."

It's a cross-platform. I have used it in MacOSX, GNU/Linux and MSWindows, (of
course that can work with all the Unix flavours) so, I don't understand why are
you saying that "does not seem to be useful for Xenomai"


> And there is a zoo of such build systems out there, what about bazel,
> scons, rake ... ? So i guess i am against adding support for any such
> thing to xenomai, especially if its OS abstractions do not match --
> like it seems to be the case for CMake.

Well, I would prefer that Xenomai works with any build system ...

Leopold


[1] www.cmake.org
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180406/7960c4c6/attachment.sig>

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Leopold Palomo-Avellaneda]

Hi

On 06/04/18 11:36, Lange Norbert wrote:
[...]

> 
> Google for "FindXenomai" to see that I am hardy the only one with that need.
> What I would like is to have a proper solution for Xenomai, and my way of doing that
> is to get criticized from people-in-the-know.

I have done a "FindXenomai" and I have found several projects. I did myself one,
based in the ROS one, and the Orocos people has another for instance.

You are not alone in the darkness ... ;-)


Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180406/d9681e91/attachment.sig>

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

>- none (--no-auto-init)
 >- bootstrap-pic.o (--auto-init-solib)
 >- bootstrap.o (--auto-init or default)
 >
 >To me the questions then are:
 >- The code there could be encapsulated in a header?
I dont see how it could not, it just uses public API
 >- or could be put in a lib?
As static lib: Not a good idea, as you would then need to pull the code in (ld just links objects which have referenced symbols)
As dynamic lib: Not entirely possible, and even less flexible than now. However helper-code should be put there (parsing "/proc/self/cmdline")
 >- only could be done in this way?

I actually added the "regular" booststrap linking in the object file,
https://github.com/nolange/cmake_xenomai/blob/master/examples/posix/cyclictest/CMakeLists.txt
Note that this will automatically decide whether to use the bootstrap.o or bootstrap-pic.o variant.

But I don’t like how this is done. You could use any kind of different compilerflags,
and separating the "bootstrapping" itself (configuring Xenomai + promoting the main thread)
from the "other" stuff (handling "--help" and adding a main method) would give you
a lot flexibility.

>Regarding to CMake, I solved this passing this arguments to VARS to cmake. So,
 >tge FindXenomai was a simple wrapper to xeno-config to obtain the correct
 >values
 >to build the xeno application.

The VARS approach is fragile, and won't play nice if you have a project
where you build multiple apps/libraries - some not using Xenomai.
Just think of unit-tests that run on plain Linux.
The "modern" CMake approach is to expose targets you can link to.

 >
 >If my memory doesn't fail it was something that Gilles recommend some years
 >ago.
 >The best way to build a xenomai application is to use the xeno-config output to
 >obtain the correct values.

The best way ist to "concentrate" the knowledge in the Xenomai project,
so Xenomai-4 will (hopefully) just build with your project.
This does not have to be isolated to xeno-config, which has some problems
If you have a relocatable build environment (and should not contain baseline and optimization  flags from the toolchain)

 >
 >So, my point of view is that you don't have to modify anything from Xenomai to
 >use it with CMake. Another thing is the bootstrap stuff that maybe it's a bit
 >ugly.

No, you don't have to, but some changes could make it more robust,
namely putting the bootstrap functionality in a header
and having the flags accessible without needing to execute a tool (even if it’s a shell-script).

I am still torn between whether a FindXenomai would be fitting better in CMake or Xenomai.

In CMake it would be easy to use, even with already released Xenomai Versions,
and easy to just add into your own project so you don’t need a not-yet-released CMake.
It might totally break down in the future, should Xenomai (4) have drastical changes.

In Xenomai, it would be easier to maintain and getting out information like the version
could be just ironed in when installing. It would need more changes to Xenomai however,
and this doesn’t help anyone with an already released version, so you will need an additional
Method of supporting those.

Norbert
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Henning Schild]

Am Fri, 6 Apr 2018 17:37:06 +0200
schrieb Leopold Palomo-Avellaneda <leo@alaxarxa.net>:

> Hi
> 
> On 06/04/18 11:36, Lange Norbert wrote:
> [...]
> 
> > 
> > Google for "FindXenomai" to see that I am hardy the only one with
> > that need. What I would like is to have a proper solution for
> > Xenomai, and my way of doing that is to get criticized from
> > people-in-the-know.  
> 
> I have done a "FindXenomai" and I have found several projects. I did
> myself one, based in the ROS one, and the Orocos people has another
> for instance.
> 
> You are not alone in the darkness ... ;-)

Ok, then go ahead and share it, at least with Norbert.

Henning

> 
> Leopold
> 
> 

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Henning Schild]

Am Fri, 6 Apr 2018 17:33:20 +0200
schrieb Leopold Palomo-Avellaneda <leo@alaxarxa.net>:

> Hi,
> 
> On 06/04/18 10:47, Henning Schild wrote:
> 
> [...]
> 
> >>  >Thanks for sharing this. IIRC, we have some Xeommai user
> >>  >in-house as well who looked into cmake, need to check the status
> >>  >and scope again (maybe Henning knows more). Could be
> >>  >interesting, indeed.    
> >>
> >> If I may ask, are you using the "boostraps" from Xenomai or some
> >> own init-code? (that’s currently the biggest headache remaining)  
> > 
> > No, i do not know anyone using CMake with Xenomai, so i would not
> > know how to deal with bootstrap there.  
> 
> I use CMake ...
> 
> >>  >
> >>  >For my understanding: You need cmake upstream changes to make
> >>  >things work? Or is this project something that could eventually
> >>  >be carried in Xenomai upstream, just requiring some cmake
> >>  >version >= X?    
> >>
> >> No strict need to upstream the scripts in either Xenomai or CMake,
> >> the files just need to be in the search-path of CMake to be usable
> >> (likely doesnt need anything newer than CMake 3.0 but would need to
> >> test this). I value the feedback from both communities,
> >> particularly because I don’t use anything but the Posix/Cobalt
> >> Skin and getting it into CMake would be the best thing for
> >> maintenance.  
> > 
> > It would probably be a good idea to try and mainline it in one of
> > the two projects. And my guess is that CMake would not really fit
> > and they might not want such code.
> >   
> >> Nevertheless it could be really helpful to add a headerfile in the
> >> Xenomai distribution, replicating the steps that
> >> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts
> >> of the functionality like the main wrapper. That glue code would
> >> ideally be built together with libraries/executables using it
> >> (identical flags and such). Right now the code is mostly
> >> duplicated and placed with the CMake Scripts, which is not ideal.  
> > 
> > I did not fully understand the bootstrap with regard to cmake yet.
> > But the magic wrapping is not pretty, also in other regards. So
> > patches that improve that, while actually targeting something like
> > CMake, would be welcome.  
> 
> Maybe I didn't understood deeply the problem here, but when I switch
> to Xenomai -3 I got it.
> 
> When you were working with Xenomai-2, and you create your program,
> then using xeno-config you could obtain your main information to
> compile and link.
> 
> So, if you want to build your posix program, xeno-config gave you:
> 
> $ xeno-config --skin posix --ldflags
> -Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers
> -L/usr/lib/x86_64-linux-gnu -lpthread_rt -lxenomai -lpthread -lrt
> 
> $ xeno-config --skin posix --cflags
> -I/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -D__XENO__
> -I/usr/include/xenomai/posix
> 
> 
> With Xenomai-3, you obtain similar parameters with cflags:
> 
> $ xeno-config --skin posix --cflags
> -I/usr/include/xenomai/cobalt -I/usr/include/xenomai -g -O2
> -fdebug-prefix-map=/build/xenomai-3.0.6+ds2rtnet=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE
> -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__
> -D__COBALT_WRAP__
> 
> But, ldflags:
> 
> $ xeno-config --skin posix --ldflags
> -Wl,--no-as-needed -Wl,@/usr/lib/x86_64-linux-gnu/cobalt.wrappers
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
> -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread
> 
> Here note that to your program you must add and object:
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o
> 
> that depends on the --auto-init|auto-init-solib|no-auto-init option
> and could be:
> 
> - none (--no-auto-init)
> - bootstrap-pic.o (--auto-init-solib)
> - bootstrap.o (--auto-init or default)
> 
> To me the questions then are:
> - The code there could be encapsulated in a header?
> - or could be put in a lib?
> - only could be done in this way?

Ok, i am starting to understand the issue here. A lib or header sounds
good, if that can be done.

> Regarding to CMake, I solved this passing this arguments to VARS to
> cmake. So, tge FindXenomai was a simple wrapper to xeno-config to
> obtain the correct values to build the xeno application.
> 
> If my memory doesn't fail it was something that Gilles recommend some
> years ago. The best way to build a xenomai application is to use the
> xeno-config output to obtain the correct values.

Yes, no matter what build system you should call xeno-config from it,
and not copy and paste its output around.

> So, my point of view is that you don't have to modify anything from
> Xenomai to use it with CMake. Another thing is the bootstrap stuff
> that maybe it's a bit ugly.
>
> 
> > Now regarding CMake itself. Is not one of its main purposes to be
> > platform independant, that does not seem to be too useful for
> > Xenomai.  
> 
> I don't understand exactly what do you want to say. CMake, from its
> webpage [1]
> 
> "CMake is an open-source, cross-platform family of tools designed to
> build, test and package software."
> 
> It's a cross-platform. I have used it in MacOSX, GNU/Linux and
> MSWindows, (of course that can work with all the Unix flavours) so, I
> don't understand why are you saying that "does not seem to be useful
> for Xenomai"

Sure i know cmake and use it myself, it can be useful. That comment was
to prepare an argument against merging cmake-specific changes into
Xenomai. Because there are many useful build-systems, tools etc. But it
is not the job of this project to cater for them.
Improve the bootstrap to enable cmake and others, Sure. Add
FindXenomai ... not so sure. ... IMHO

We had a similar discussion of whether or not to drop /debian/ because
it just caters for one of many distros. In this case i was actually for
keeping it ;).

> 
> > And there is a zoo of such build systems out there, what about
> > bazel, scons, rake ... ? So i guess i am against adding support for
> > any such thing to xenomai, especially if its OS abstractions do not
> > match -- like it seems to be the case for CMake.  
> 
> Well, I would prefer that Xenomai works with any build system ...

Same here.

Henning

> Leopold
> 
> 
> [1] www.cmake.org