> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to
> have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.
You can explicitly use the cobalt or std function with macros.
That said I have my issues with cascading headers from linux, c library and
cobalt,
this is hard to follow with symbols potentially coming from anywhere.
> Norbert, I have followed your emails and your project. You did a good job,
> but I don't agree with your approach. My points are:
>
> - You are trying to convert Xenomai a CMake project and this probably will
> not happen because Upstream is very happy with the autotools. I don't like
> to touch anything from upstream. Maybe some patch, but incorporated in
> Upstream.
Sorry, that's nonsense, never thought about building Xenomai with CMake.
> - I would prefer follow the Upstream guidelines that recommends use xeno-
> config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.
I tried multiple approaches, using xeno-config fell out shortly.
- it's (logically) an target "executable".
That imposes problems with CMake's normal search for those,
not to mention CI when your builder works in a partition with noexec.
I would want to use config-files directly or with a host-executable,
like pkg-config uses .pc files.
- has problems if you relocate your build environment
I would prefer relative paths for simplicity
- I need to extract all information and not just flags for ONE configuration
That’s the most important issue, I need the "building blocks" of the command
line, not ONE commandline. This means you need to know xeno-config
and its flags precisely and figure out how to dissect multiple outputs
in those "building blocks".
Fragile and not forwards-compatible.
Whats left is two variants:
FindXenomai - this would be placed in your project or up streamed in CMake.
Uses CMake functions to guess the paths, this might be hard to do with some
libdir / includedir
Configurations and would need to be updated independently of Xenomai.
CMake Config files - you place those in <libpath>/cmake/xenomai.
Those can be generated by config/install_cmakeconfig.sh from the repo (use same
arguments as when configuring CMake).
The previously mentioned patchset adds those files to Xenomai and does this
automatically when installing (using the autotools system).
Upstreaming in Xenomai would make everything hassle-free and
forwards-compatible (the config files would always match the version).
The downside is of course that this would then be a burden to the Xenomai devs,
but it should not need any changes outside of structural changes.
At which point someone will have to adapt CMake integration, however its done -
I would prefer it to be done just once
The repo contains other changes, attempting to sanitize the bootstrapping
methods,
Without those the provided examples might not work (only the upstream
bootstrapping method will work).
I hope atleast those can be upstreamed.
> - I agree with Norbert that bootstraped code is not a good idea. But this
> change should be done by upstream. But if I'm not wrong, Phillipe said that it
> hasn't an easy solution.
It has no easy solution if you want to do build a POSIX-only project purely
with linker arguments.
When you can afford add some lines of (Xenomai-specific) code to your project,
it opens a lot possibilities.
>
> But for the curious, I have done this example:
>
> https://github.com/iocroblab/xenomai-cmake
>
> but it's not polished and had some mistakes. The idea is to use any Xenomai
> installation without touched and then use CMake to build your application.
Yes I get that, and I tried the same with FindXenomai. I consider the CMake
Config approach
a lot better.
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
