Xenomai + conan + cmake: Building with less headaches

Xenomai + conan + cmake: Building with less headaches

[Lange Norbert]

This is some scheme I am trying to cook up for our internal development,
which should produce production binaries, and offering them for local
development.

It uses Xenomai 3.0.9, some time after 3.1 is released and I am less stressed
with other work I plan to clean up all involved stuff, so consider this a
preview.

Conan is not dependent on CMake, CMake is not dependent on Conan,
but the integration between those 2 is far better than other options.

## Developing with conan

this takes care of the dependencies (and their dependencies),
the basic idea is that you run `conan install ...` the dependencies end up
somewhere and the cwd has a script for your buildsystem to resolve those.

(Packaging for conan is harder, my attempt is at [2])

## Developing with CMake

CMake is one of the supported buildsystem, and I rigged up a patchset to add
support for Xenomai (I would want to upstream this one day).
As said, this is not strictly required but eases up integration.

CMake will take care of all those wrapper flags and bootstrap code.

## Big picture

I attached one small project, ripped from Xenomai and augmented with
CMake + conan files. A small script "build.sh" should be called from
*ouside* the source tree.

What this does is:

1)  Resolves the dependencies - in this case Xenomai.
It will try to resolve a binary first, this means the first time you will
build the Xenomai libraries, the next time you will reuse a cached version.

2)  Configures the project, CMake will pick up the dependencies

3)  Build

For a developer this means he just needs to install a local toolchain
(or none at all if the system compiler is sufficient for ex unit tests).
The packages can come from a variety of sources:

-   Existing open source packages (like gtest, xmlparsers, etc...).
    if your architecture fits, you wont even have to compile once.
-   Locally shared packages. ie.: production binaries, typically by build-servers
-   Locally cached binaries. Your own builds, but potentially shared across projects

What I would want in the longterm is to get [1] upstreamed (after a cleanup or 2),
the source package is uploaded to [2].
Going even further, the the conan packages could be built and uploaded for common enough targets, so building the example attached will work for ex. on plain x86 debian.

Regards, Norbert

[1] - https://github.com/nolange/cmake_xenomai
[2] - https://bintray.com/nolange79/conan/xenomai3%3Axenomai3
________________________________

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
________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyclictest.tar.xz
Type: application/octet-stream
Size: 21232 bytes
Desc: cyclictest.tar.xz
URL: <http://xenomai.org/pipermail/xenomai/attachments/20200109/177169c9/attachment.obj>