CinderBlocks

Specification

<cinder>
    <block>
    ...
    <block>
<cinder>

<header>include/example.h</header>

<platform os="msw">
    <header>include/myLib.h</header>
    <platform config="debug">
      <staticLibrary>myLib_d.lib</staticLibrary>
    </platform>
    <platform config="release">
        <staticLibrary>myLib.lib</staticLibrary>
    </platform>
</platform>

Creating Template Projects

<cinder>
  <block>
    ...
  <block />
  <template>path/to/template.xml<\template>
    ...
  <template>path/to/another/template.xml<\template>
</cinder>

<cinder>
    <template name="OpenCV: Basic"
        parent="org.libcinder.apptemplates.basicopengl">
        ...
    </template>
</cinder>

Best Practices for Maintainers

• Include an icon: TinderBox will detect and show a cinderblock.png if present. This should be at least a 72x72 pixel PNG with an alpha channel.
• Setup a git repo: In order to allow users to include your library as a git submodule, it must have its own git repository.
• Consider minimalism: In many cases a minimal CinderBlock-specific API is preferable. An example is the Cinder OpenCV block, which serves more as a shim than as its own interface. Particularly when a library is already object-oriented, it may be the best design decision. It requires less maintenance and allows a user who is already familiar with the library to utilize her knowledge of it, rather than having to learn an "API to an API".
• Pursue loose coupling: For visually-oriented CinderBlocks, this may mean separating the render logic out into other classes or functions, particularly in the sense of not assuming an application is using OpenGL.
• Weigh binaries: In many instances a static library is unnecessary, and simply including a library's source files is adequate. This simplifies maintenance and allows the library to be used on platforms you may not have immediate access to. The CinderBlock for Box2D is an example of this technique. Other libraries, like OpenCV, must be static libraries. A natural decision maker would be whether the library requires a build system like CMake.
• Favor static over dynamic libraries: Cinder apps are designed to be self-contained whenever possible. 

OS X & iOS

• Libraries should be universal binaries, supporting the i386 and x86_64 architectures on OS X and the armv7 and arm64 architectures on iOS.
• Where necessary, the C++ stdlib should be libc++, and the C++ Dialect must be C++11. 

Windows

• Make sure the C Runtime is Multithreaded Debug (/Mtd) for debug and Multithreaded (/MT) for Release. 

Advanced: Custom App Templates

Advanced users may want to create new App template types. An organization may have a style they'd like all applications to conform to, or you may find yourself creating the same sort of application frequently. These templates are located at Cinder/blocks/__AppTemplates. Inside you'll see a directory for each of the default application types, and you can create your own here as well.

Very advanced users may find cause to modify lower level parameters of the Xcode and Visual C++ project files TinderBox creates. If you are familiar with the internals of your compiler's project files, you can modify the files located at Cinder/blocks/__AppTemplates/__Foundation. A key attribute of these files is that the string _TBOX_CINDER_PATH_ will be replaced with the absolute file path to Cinder, and the string _TBOX_PREFIX_ will be replaced with the user-provided project name.