>-----Original Message----- >From: Henning Schild [mailto:henning.sch...@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.la...@andritz.com>: > >> Hello, >> >> >-----Original Message----- >> >From: Jan Kiszka [mailto:jan.kis...@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 ________________________________ _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
