1. SYNOPSIS

xeno-config

xeno-config --v | --verbose

xeno-config --help

xeno-config --info

xeno-config --core

xeno-config --version

xeno-config [--cc] [--ccld] [--arch] [--prefix] [--posix|alchemy|rtdm|psos|vxworks|smokey] [--compat] [--auto-init|no-auto-init] [--auto-init-solib] [--cflags] [--ldflags] [--library-dir|--libdir|--user-libdir]

2. DESCRIPTION

xeno-config is a shell script which is aimed at retrieving the Xenomai build configuration data, such as the compiler and linker flags required for building applications. For this reason, xeno-config is typically used in Makefiles.

xeno-config --verbose dumps the build configuration data in a human-readable format.

Invoking xeno-config without any options is equivalent to running xeno-config --verbose --help.

3. OPTIONS

--v, --verbose

Output all configuration information in a human-readable format.

--help

Output the list of available command-line options. The command exits immediately after completion.

--version

Output the Xenomai version.

--cc

Output the path to the C compiler command used to build the Xenomai libraries and utilities, which is therefore suitable for compiling a Xenomai application.

--ccld

Output a C compiler command suitable for linking a Xenomai application.

--arch

Output the target CPU architecture Xenomai was compiled for, e.g. arm, x86, powerpc etc. This may differ from the CPU architecture of the current system, if cross-compiling.

--prefix

Output the absolute path to the Xenomai installation directory.

--[skin=]{posix, alchemy, rtdm, psos, vxworks, smokey, cobalt}

Select the API/skin for which xeno-config should print the information required. The skin= prefix is optional and may be omitted, e.g. --posix is equivalent to --skin=posix, selecting the POSIX API.

Note --native and --skin=native are accepted for backward compatibility purpose. They are stricly equivalent as passing --alchemy --compat. Likewise, passing --rtdm or --skin=rtdm is stricly equivalent as passing --posix, enabling POSIX I/O routines to be wrapped to their respective Xenomai implementation.
Caution Over Cobalt, only xeno-config --posix --ldflags (or --rtdm as an alias) returns the proper linker flags to cause POSIX routines invoked by the application to be wrapped to their respective Xenomai implementation. No other API will imply such wrapping. For this reason, --cobalt --ldflags should be used for linking exclusively against the Cobalt library (i.e. libcobalt.so) without symbol wrapping. Conversely, mentioning --posix along with other API switches with --ldflags will cause POSIX symbol wrapping to take place, e.g. use --posix --alchemy --ldflags for mixed API support with POSIX symbol wrapping.
--cflags

Output the C compiler command-line options (CFLAGS) which are required to compile applications based on the selected Xenomai API/skin.

--ldflags

Output the C compiler command-line options (LDFLAGS) which are required to link applications based on the selected Xenomai API/skin.

--library-dir, --libdir, --user-libdir

These switches are synonyms, for retrieving the absolute path to the Xenomai libraries.

--auto-init
--no-auto-init

All Xenomai APIs but POSIX are based on the Copperplate library, which automatically initializes when the application process starts. --no-auto-init can be passed to disable such initialization. In such a case, the application code shall call the copperplate_init() routine manually, as part of its initialization chores on behalf on the main() routine, before any real-time service is invoked.

This flag makes sense when passed along with --ldflags only. xeno-config enables the Copperplate auto-init feature by default.

--auto-init-solib

This switch enables the auto-initialization feature described above for a shared library target instead of a pure executable. The main difference resides in a position-independent (PIC) glue code being used for bootstrapping the initialization.

The bootstrap code runs when the shared library is attached to a running executable, either because it appears in the static dependencies of this executable, or when loaded dynamically via the dlopen() interface.

--core

Output the name of the real-time core the current Xenomai installation was built for. The possible values are cobalt or mercury, depending on the configuration switch --with-core used for building the Xenomai libraries and utilities.

--compat

Enable the Xenomai 2.x compatibility mode for the API/skin selected. This switch affects the Alchemy and POSIX APIs, turning on a set of source-level compatibility wrappers when present.

--info

Dump information about the running Xenomai-enabled system. Unlike most other options, --info is aimed at being used on the target system running Xenomai, for retrieving the current setup information. The output of such command is a valuable information when reporting any runtime issue to the Xenomai mailing list. The command exits immediately after completion.

4. ENVIRONMENT VARIABLES

DESTDIR

Xenomai’s handling of DESTDIR is conformant to the GNU coding and installation standards, for generating pathnames rooted at some staging area on the build system. Such staging area is commonly NFS-mounted from the target system running Xenomai.

If the DESTDIR variable is set in the environment of xeno-config, its contents is prepended to all directory and file names based on the Xenomai installation root which may be output by the command.

If DESTDIR was set when installing Xenomai - typically after cross-compiling - DESTDIR must be set to the same value before calling xeno-config for accessing the target-based directories and files from the build system.

e.g.

$ configure --prefix=/usr --includedir=/usr/include/xenomai
$ make install DESTDIR=/nfsroot/target
$ DESTDIR=/nfsroot/target /nfsroot/target/bin/xeno-config --alchemy --cflags
-I/nfsroot/target/usr/include/xenomai/cobalt
-I/nfsroot/target/usr/include/xenomai -D_GNU_SOURCE
-D_REENTRANT -D__COBALT__
-I/nfsroot/target/usr/include/xenomai/alchemy

5. EXIT STATUS

0

Success.

non-zero

Error.