Use cargo-c instead of cmake

[nappa85]

cargo-c exists exactly to ease the build of Rust programs into C libraries, it's an easier and less error-prone approach than managing the cmakefiles yourself.

[elBoberido]

We also need to support colcon via cmake and as far as I understand cargo-c, this is not easily possible. We need cmake to integrate into the C and C++ world, not to integrate C and C++ libraries into iceoryx2.

If I didn't miss anything, we are not able to use cargo-c.

[nappa85]

cargo-c produces a platform-correct shared library a pkg-config file and one or more headers, cmake can consume the pkg-config files fairly easy. Il mar 29 ott 2024, 18:45 Mathias Kraus ***@***.***> ha scritto:

…

We also need to support colcon via cmake and as far as I understand cargo-c, this is not easily possible. We need cmake to integrate into the C and C++ world, not to integrate C and C++ libraries into iceoryx2. If I didn't miss anything, we are not able to use cargo-c. — Reply to this email directly, view it on GitHub <#418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZXINLMBKRJRMNJO5LGZI3Z57CSHAVCNFSM6AAAAABPCTXFRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUHE2TGMBVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[elBoberido]

Does this also easily work with cross compilation and on more exotic OSes like QNX and VxWorks?

I'm a little bit hesitant to add another layer of indirection since the cmake files are not that complex and we are little bit burned by the - supposedly simple - bazel.

[nappa85]

Does Rust works on QNX and VxWorks? Il ven 1 nov 2024, 18:09 Mathias Kraus ***@***.***> ha scritto:

…

Does this also easily work with cross compilation and on more exotic OSes like QNX and VxWorks? I'm a little bit hesitant to add another layer of indirection since the cmake files are not that complex and we are little bit burned by the - supposedly simple - bazel. — Reply to this email directly, view it on GitHub <#418 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZXINOHPEXM5E3A7XLME4DZ6OYU3AVCNFSM6AAAAABPCTXFRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGI2TGMRSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[elBoberido]

It works on QNX and I think also VxWorks but I not so sure about the latter. We want to target both OSes and even more exotic ones like eMCOS which are used in safety domains.

[lu-zero]

Does this also easily work with cross compilation and on more exotic OSes like QNX and VxWorks?

The two targets aren't currently supported since I'm taking a conservative approach since every platform has its own set of details for shared libraries.

If you have experience with any of those platform target I'd welcome a pull request to add the necessary informations:

• if the platform uses soname to embed the library version in the library (common on unix-like elf systems)
• which is library naming convention (e.g. lib{name}.so vs name.dll, symlinks over version minor/major)

For people with access to the platform it would take 10 minutes to prepare the patch. eMCOS isn't currently even present in the documentation so I guess its addition is very recent.

[elBoberido]

eMCOS is something we recently put on our interesting project list. It is quite often used in safety critical domains, similar to VxWorks and QNX.

We also need to be conservative, since at some point everything needs to be either certified or qualified, which is very costly. Some of the dependencies we currently have will also be replaced by tailored, custum implementations due to that.

cargo-c is for sure a great project, but for us it does not add as much value as for other projects and we also do not have a complex CMake setup.

[lu-zero]

Adding the cargo-c metadata doesn't prevent you from using your custom machinery for custom targets, but makes the life of linux distributors much easier.

If you are planning to use ferrocene, cargo-c can use that compiler as any other versions of rustc.