Home

Anonymous Abe Bachrach

What are pods?

A pod is a piece of software that adheres to a small set of guidelines standardizing some aspects of how other things interact with the pod. The primary purpose is to make it easier to integrate many smaller pieces of software together into a larger system by agreeing on how pods present their external interfaces. More concretely, the guidelines dictate where a pod places its public-facing files -- executables, header files, libraries, python modules, jar files, etc.

A pod can be as simple or as complex as necessary, providing anything from a single shell script to a set of libraries and tools written in multiple programming languages. It's important to note that the pods policies enforce no restrictions on the internal structure and organization of a pod, and are primarily concerned with the external aspects -- the parts of the software that other people or programs interact with.

Why pods?

When developing a new piece of software, one issue is how to organize the software's external aspects. For example, if building a few executables, where do those executables get placed? If building a library of useful functions for other programs to use, where should the public header files and the compiled library files go?

On most operating systems, there are well-known standards if the software is to be installed system-wide (e.g., header files go in /usr/include). However, a lot of software is not meant to be installed to a system-wide location, and the organization of this kind of software is usually decided by the individual programmer, with the end result being lots of people making lots of different choices.

This becomes a problem when people want to share software, as it introduces the extra headache of integrating build systems, messing with Makefiles, juggling files and directories around, etc. Organizational practices that worked for one person and one piece of software may no longer work for larger systems, and the seemingly simple task of two people trying to collaborate quickly becomes a build system nightmare.

The primary motivation behind Pods is to introduce some policies governing software that might be shared with others, but may not be intended for system-wide installation. The driving design principles are simplicity and modularity, to make it easier for researchers to develop software that others can use.

Core Policy

The Pods Tool

The pods tool contain a set of templates to make it easy to write software that adheres to the pods principles. The templates provide an organized directory structure, and a set of build scripts based around cmake which provide a very easy to use build system that adheres to the pods guidelines.

  • PodsTool -- download and installation instructions for the pods tool

Adapting Existing Code

Adapting an existing code base is usually quite simple since pods does NOT require the use of any particular build system. The changes will be particularly easy if the build system is already configured with an "install" target that installs to the system wide path.