CorePolicy

Core Policy

This is the core policy.

Pod name and directory structure

Every pod has a name. This name should be unique. All of the software inside a pod should be contained in a directory with the same name as a pod.

The following command should be sufficient to build / compile the software in a pod:

 $ cd <pod-directory>
 $ make

For example, for a pod named 'mypod', you could run

 $ cd mypod
 $ make

Note that if you don't like make, the makefile can be a wrapper around your favorite build system.

The build prefix

The central notion behind a pod is that all of the public-facing portions of a pod will be placed in a subdirectory of a ''build prefix''. For example, if a pod produces an executable program named hello-world, the program will be placed at:

<build-prefix>bin/hello-world

The first time a pod is built, the build-prefix can be specified as a make variable:

 $ cd <pod-dir>
 $ make BUILD_PREFIX=/path/to/build/prefix

If not specified as a make variable, then the pod searches up to 4 parent directories for a build directory (e.g., ../build, ../../build, etc.) and uses the first one it finds.

Finally, if no parent directory contains a build directory, then it defaults to <pod-dir>/build.

Makefile targets: All, Clean

The makefile for a pod should provide the targets 'all' and 'clean'. The default target must be 'all'. Their behavior should be:

• make all -- Builds all the public-facing software for a pod.
• make clean -- Removes built/compiled files and public-facing software.

File locations

Public-facing files for a pod sh ould be placed in the following locations, relative to the build prefix.

• executables -- bin/
• C, C++ header files -- include/
• shared, static libraries -- lib/
• pkg-config files -- lib/pkg-config
• Python modules -- lib/pythonX.Y/site-packages (X.Y == python version e.g., 2.6)
• Java .jar files -- share/java