Development Environment

Setup scripts for bash and tcsh are provided in the DAT group space in /afs/slac.stanford.edu/g/cci/ to facilitate setting up your working environment. The scripts are setup.sh and setup.csh, and it must be source'd to update your environment.

The script is maintained to provide the user with the currently sanctioned versions of packages we depend upon. In turn, appropriate setup scripts are called by the script to set up the environment for those packages and the packages they depend on. For the time being, there are only a few such packages:

• Xilinx
• Synplicity
• RTEMS
• gnutools
• autoconf
• automake

Xilinx, Synplicity and RTEMS version numbers can be overridden by calling the script with appropriate arguments. Take a look at ~claus/dat/envs.sh for one way to do this. Similarly for the default BSP you plan to use.

If additional environmental set-up is desired that you deem is of interest to the group, feel free to add it to the script.

Build Environment

• Currently, all tools are deployed on AFS
  • We use GNU tools set up for cross-compiling for the PowerPC architecture
  • As of 2011/03/24, these tools are installed under /afs/slac/g/cci/package/gnu/. See the setup.{sh,csh} files mentioned above for more information. This isn't actually true, gnu is a softlink to /reg/g/common...
• The Data Acquisition Toolkit (DAT) uses SVN for configuration management:
  • SVNROOT == file:///afs/slac.stanford.edu/g/cci/svnrepo

Checking out the code from the repository

Checkout top level release directory (svn co $SVNROOT/release/trunk release) and cd into it.
This directory contains the Makefile infrastructure.

Checkout the core of the RCE system:

svn co ${SVNROOT}/rce/trunk rce
svn co ${SVNROOT}/rceusr/trunk rceusr
svn co ${SVNROOT}/rceapp/trunk rceapp

The ideas behind these three projects are as follows:

• rce/ provides common infrastructure that should be re-usable for all software that runs on the RCE. It is like a C++ extension of the RTEMS BSP (e.g. network, thread wrappers, ethernet/PGP PIC drivers).
• rceusr contains higher level code that can be reused (e.g. libraries to support a console application, or a particular use of PGP).
• rceapp contains the highest level executables.

Building

There are several files of importance to building executables:

1. toplevel/projects.mk contains the list of projects that will be built
2. toplevel/compilation.mk contains the compilation settings
3. toplevel/project/packages.mk contains the list of the project packages that will be built.
4. toplevel/project/package/constituents.mk contains the detailed build instructions for each package.
5. Each level also includes its own Makefile. Under most circumstances, these are copies of the templates under toplevel/make/sw
   • These files may need to be modified in order to allow non-standard compilation. For example, if your package contains a python interface that needs to be compiled with swig, you would add the line include $(RELEASE_DIR)/make/sw/python.mk to toplevel/project/package/Makefile
6. The support files for make are under toplevel/make.

To build, we use the GNU make supplied with RedHat. The Makefile system provides several default architectures, the purpose of which should be self-explanatory:

• i386-linux
• ppc-rtems-rce405

Appending -opt to the architecture name will build optimized, and -dbg will build with debugging information.

There is at least one command line tag we can supply to make which provides more information: make <target> verbose=y will display all commands used to build, rather than just progress messages.

The make commands can be issued at the top level to build the specified architecture for all projects in the release, at the project level to build all packages for that project or at the package level to build one package only. Note that:

gmake rceapp.console.ppc-rtems-rce405

and

cd rceapp/console
gmake ppc-rtems-rce405

are equivalent.

Note that we use shared libraries on Linux, but with the much-improved-but-not-perfect $ORIGIN approach for locating shared libraries, so there is no more LD_LIBRARY_PATH or RPATH to worry aboutDead page.