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> _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
