Source Code

From Sirikata Wiki
Revision as of 13:49, 22 December 2011 by Mialuna24h8 (talk | contribs)
Jump to navigation Jump to search

The Short Version

The Long Version

Our code is hosted on GitHub. Besides hosting and serving our code for us (thanks GitHub!), they provide a bunch of useful addons - tracking of forks, simple merge procedures, and stats tracking to name a few. It's not necessary that you use an account on github to develop Sirikata, but you might want to check it out. Especially if you want to do some experimental development or just work outside the main tree for awhile, its a nice way to easily track the mainline fork. Overall Git is a great a distributed version control system but it takes some getting used to so you may want to check out some tutorials.

To actually get started with the code you'll want to get it from our GitHub repository and then follow the build instructions.

Building Sirikata can be a complicated affair: it's a large piece of complex, platform independent software with a number of dependencies. Even worse, we currently have a limited number of test systems, generally those that the developers are working on. We would very much appreciate reports of any problems sent to the developer list, or even better would be fixes.

For reference, the current core developers have Linux, Mac and Windows machines. Most heavily favor Linux, especially the Ubuntu distribution. tracking of forks, simple merge procedures, and stats tracking to name a few. It's not necessary that you use an account on github to develop Sirikata, but you might want to check it out. Especially if you want to do some experimental development or just work outside the main tree for awhile, its a nice way to easily track the mainline fork. Overall Git is a great a distributed version control system but it takes some getting used to so you may want to check out some tutorials.

Submodules

As mentioned above, Sirikata has a large number of dependencies. Some of these are general purpose tools that Sirikata developers have built, but we didn't want to live in our repository. They are effectively independent projects, but Sirikata's development is much more tightly coupled with these projects than with other dependencies. Therefore, we take advantage of Git's submodule feature to make our developer's lives easier.

In short, submodules directly link to another Git repository, allowing Sirikata to track those source trees with little overhead. Submodules are pinned to a specific revision, so developers must explicitly update a submodule before new changes become available. This requires manual intervention, but is better in general because broken builds, instabilities, and other issues in the references project do not flow uncontrollably back into Sirikata.

In the source tree, all submodules are stored in sirikata/externals/, where sirikata is your top-level checkout. (For the curious, the name externals is a holdover from a very similar feature in Subversion.) Currently we reference the following submodules:

  • Berkelium - A library built around Chromium which renders to offscreen buffers, allowing easy embedding of web pages in any app. Used in our Ogre plugin to embed web pages and for UI elements.
  • cxxtest - The testing framework our system uses.
  • pbj - Protocol Buffers and Jelly, a wrapper around Protocol Buffers which adds some Virtual World specific types and performs validation on these values. Could also support other serialization formats in the future.
  • prox - Library of efficient data structures for resolving local (non-distributed) proximity queries. The name is outdated, it actually handles more than just proximity queries.

Developer Preview (Prototype) Code

The current incarnation of Sirikata has its origins in a old prototype that was completed in late 2008. This is available as a developer preview. Only the curious and brave will want to check this out; building it is more difficult than the current version.specific revision, so developers must explicitly update a submodule before new changes become available. This requires manual intervention, but is better in general because broken builds, instabilities, and other issues in the references project do not flow uncontrollably back into Sirikata.