Products Support Documentation Download
UNIX, Linux, or OS X Source Package Build

Introduction

Our standard deliveries for RDM on Linux, Unix, and OS X are object packages that are shipped as self-extracting archives. A source package on the other hand is shipped as a gziped tar archive. An object package is targeted for a platform while a source package targets all targets. Where there are many object packages, one for each target, there is only one source package.

The source package you have is also the source package we use in our release-system to build artifacts that are staged to create an object package. Our release-system contains additional scripts for this but other from that, it is the exact same source we use and the environment described therein. These additional scripts are calling into or extracting content from scripts included in the source package. One such set of scripts included are the custom configure scripts located in several directories under the target directory. These configure scripts are the ones we used when configuring RDM.

Extracting a source package

To extract a RDM source package run these commands to extract it into rdm-src-14.1:

$ gunzip rdm-src-14.1-enc.tar.gz
$ tar xf rdm-src-14.1-enc.tar

Using the extracted source

Using a source package is not much different than using an object package. For the most part you will be able to follow the instructions outlined in the following references:

There are a few differences you will need to be aware of.

References to the install directory

Any reference to the install directory in the above-mentioned links must be replaced with a reference to the source directory. That is the subdirectory created where the source was being extracted to.

No precompiled tools or libraries

An object package has precompiled tools while a source package does not. For a source package, the tools are being built as part of building its source. This has some unfortunate consequences.

A Cross Compile using Make

A cross compile using make will fail as described in Using "configure" and Using "make".

Tools and any other artifacts built, will only be usable on the target but since RDM compile-time tools are needed for generated source files the build will fail when these tools are being used.

The remedy to this is to use a configure option to tell where the RDM compile-time tools for the development host are located. This means that before you can do the cross compile you need a native build for the development host. When you have such a build ready, use the command line option –enable-native-build-dir to configure in addition to other options needed for the cross compile:

$ ../configure --enable-native-build-dir=<native-build-dir> \
      <other-options>

Alternatively, if you have an object package installed use the command line option –enable-native-install-dir instead of –enable-native-build-dir where you specify the location of the install directory.

A Cross Compile using Project files

A cross compile using project files is described in README-QNX.txt, README-INTEGRITY.txt, README-vxworks.txt, and README-vxworks7.txt. However, these descriptions assume the installation as an object package. With a source package, a few details are different.

For instance, when running configure additional command line options must be passed in when enabling project file. Some examples:

$ ../configure ... --enable-vxworks-project-files=PENTIUMgnu
$ ../configure ... --enable-vxworks7-project-files=x86_32
$ ../configure ... --enable-integrity-project-files=integrity11-x86
$ ../configure ... --enable-qnx-project-filesarmle-v7_g

Run configure with –help for further details.

No precompiled libraries

An object package has precompiled libraries while a source package does not. For a source package, the libraries are being built as part of building its source. Here we need to cover the different options for building libraries.

Static or Shared Libraries

The configure script will by default set up make files for both static and shared libraries. During development, you may only want one set of libraries. Run configure as follows to disable shared libraries:

$ ../configure --disable-shared

If you are doing Java development and using JDBC, you may want to only use shared libraries. Disable static libraries as follows:

$ ../configure --disable-static

In-source build

The configure script is designed for both an in-source and an out-of-source build, like CMake but contrary to the Visual Studio project files. The description in the README files assumes an out-of-source build since we want to leave the install directory intact with only the installed content.

This is less of a concern with a source package build. You could extract the same source into several directories and have builds located directly in the source directory. How you want to arrange this is up to you.

Many target directories

An object package targets one or two targets while a source package targets many targets. You will therefore see many sub-directories under the target directory instead of just one or two.

For cross compiled targets using project files for QNX, VxWorks 6.x, or VxWorks 6.x RTP you need information from two target directories instead of just one. The project files are in target/qnx, target/vxworks, and target/vxworks-rtp and the target specific settings are in a target directory prefixed with target/qnx-, target/vxworks-, and target/vxworks-rtp-.