OpenLibraries Coding Guidelines


  1. About
  2. Dependencies
  3. Repository Structure
  4. Getting Started
  5. Coding Conventions
  6. FAQ

1. About

Welcome to the OpenLibraries! A unified framework to develop real-time editing, visual effects and rich-media applications.

OpenLibraries are free to be applied for any purpose, including commercial usage and distribution. It's open-source software, released under LGPL. OpenLibraries are a true community effort and anyone is welcome to participate. This document describe some of the guidelines that the OpenLibraries team uses when developing the code. They are not exhaustive and they don't take away your freedom of expression when writing code. This document does not tell you where to put your curly braces. It simply describes a simple set of conventions to allow for proper usage of CVS and development of openlibraries aware code.

back to top

2. Dependencies

The libraries depend heavily on Boost and GLEW. RPMS for these dependencies are provided and they should be used. The module dependencies in CVS contains the RPM spec files to build these RPMS. However, other versions of Boost may be used for development and this is left to the discretion of the programmer. It is recommended, however, that the latest versions be used.

back to top

3. Repository Structure

The repository directory structure has src, test and doc directories. The top level directory is for exclusive access of build scripts and global configuration files. All the development should happen in the src directory under a library name directory (e.g. src/openobjectlib). The developer manages the directory structure after that. All unit tests will go into the test directory under a library name directory (e.g. test/openobjectlib). The doc directory follows the same conventions and it should hold users and developers guide for each of the libraries. Remember, lack of documentation prevents adoption. Proper usage of CVS must be respected at all times. Code not following these conventions will be deleted without warning. Also, it is illegal to share CVS sanboxes between multiple OS due to well known end of line characters translation issues.

back to top

4. Getting Started

To build the libraries Visual Studio solution files, XCode 2.1 projects, and autoconf based scripts are provided depending on each platform. The best way of getting started as a developer is to download the source code and have a look at the test directory to see how they are being used. It is our intention to provide full developer documentation. Although much code has been written some of it is not fully featured and is effectively entry point code for add-ons and more advanced features (this is where you come in!). Eventually all of it will be written hopefully with the help of community effort.

Source: source code tarballs are available from the OpenLibraries SourceForge web site and the source code can also be downloaded from the CVS repository:

  1. cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/openlibraries login
  2. cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/openlibraries co -P openlibraries

or, if running on Windows, with a CVS client such as TortoiseCVS.

To build the libraries Visual Studio solution files, XCode 2.1 projects, and autoconf based scripts are provided depending on each platform. Also, and to minimise the number of dependencies, and elusive ports of external code to different platforms, the OpenLibraries strive to use as much native functionality as possible. Currently there is no unified build process on all platforms. On Linux, OpenLibraries make use of the GOAT tools to manage the detection of platform characteristics and the generation of Makefiles. On Windows, Visual Studio is being used and different libraries have different solution files. At this point in time they will have to be built separately in order of dependencies. On OSX, XCode 2.1 projects exist and xcodebuild is used. In the future, however, scripts will be made available to simplify the build process, but they will still depend on the native tools of each platform.

 

back to top

5. Coding Conventions

There are no strict coding conventions. The programmer is free to use its existing conventions with a few exceptions. All OpenLibraries related source includes by means of #include will be of the form #include <name_of_library/whatever>. This allows us to keep the number of include directories specified on the command line to a bare minimum. It will avoid conflicts between files with the same name and has the potential to speed up compilation times. Namespaces are of the form namespace olib { namespace library_name {. The programmer will manage its other namespaces under this structure at will. Visual Studio solution files also follow a particular set of conventions. The VC runtime is always the DLL multithreaded version and the configuration name is Multi-threaded Debug DLL or Multi-threaded Release DLL. Please check the openobjectlib for examples.

6. FAQ

  1. What's the relationship between Jahshaka and OpenLibraries?

What's the relationship between Jahshaka and the OpenLibraries?:

We're it! The OpenLibraries project forms the technological foundation for Jahshaka.


Thanks for reading, we hope you enjoy the OpenLibraries project!

Document version 1.0, November 2005

back to top