Pixar's Devkit
Cutter's Devkit Authoring Environment


return to main index



Overview of the Features

Pixar's devkit, as of release 13.5 of prman, specifies nine API's that enable the development of a variety of plugins and executables that extend the capabilities of the RenderMan system. Cutter incorporates a number of features intended to ease the task of writing, developing, compiling and linking devkit DSOs and executables. In effect, Cutter implements a simple and easy to use devkit authoring environment. Cutter can assist users to develop the following devkit plugins and executables.

    Shadeops,
    RSL plugins,
    Ri filters,
    Procedural Primitives.
    PointClouds,
    Deep textures.
Feature 1 - Compilation and Linking

Cutter's most important feature is that devkit ".c" and ".cpp" files can be compiled and linked without the need for the user to write and maintain their own Makefiles (OSX and Linux) or Windows VS .bat files.


Feature 2 - Quick Access to Devkit Documentation

Pixar documentation can be conveniently accessed via the keyboard shortcut alt+double click (Linux and Windows) or apple+double click (OSX).




Figure 1 - Cutters internal browser


Cutters internal browser, figure 1, will search for the first instance of the text on which the keyboard shortcut was performed. The next instance of the word can be found using the return key. Alternatively, holding down the shift key with the keyboard shortcut will cause Cutter to display the web document in the users preferred external browser. This feature requires Pixar's documentation to be installed on the users computer.


Feature 3 - Opening Header Files

Header files can be conveniently opened by control+clicking in the name of the #include file - figure 2. Cutter automatically "expands" the selection to the boundaries of the file name - there is no need for the user to manually select the full name of the header file.




Figure 2 - Popup menu for opening a header file


Feature 4 - Easy Setup

The preferences for the "Pixar Devkit" are shown in figure 3. The first path specifies the path to the devkit directory in which the lib and include directories that support devkit development are located - this is a required path. The "Other Directories & Files" paths specify the location and names of additional libs and objs - those paths are optional. Preferences (Rman->Docs->Pixar Specific) should also point to the index page of the RenderMan Pro-Server documentation - figure 4.



Figure 3


Figure 4


The next section explains how the compilation and linking of DSOs and executables can customized.


Default Compilation & Linking

Upon receiving the keyboard shortcut control+e or alt+e, Cutter attempts to compile and link the DSO or executable the user is developing. It does so by running a Makefile (Linux and OSX) or a Windows Visual Studio .bat file. Such scripts can originate from one of three sources.
    - directly supplied by the user,
    - generated from a template supplied by the user,
    - generated from a template supplied by Cutter.

The majority of users will take advantage of Cutter's ability to generate and maintain its own Makefiles or VS .bat files. Cutter is able to perform this task because it makes use of resources called templates.


Customization, Templates & Placeholders

A template looks like an ordinary Makefile or VS .bat file except that it includes placeholders that are replaced by specific text after the template has been copied, but before it is saved to the users working directory. For example, this placeholder,
    _DEVKIT_PATH_
would be substituted on Linux by this text,
    /opt/pixar/devkit

Cutter automatically selects a template based on the users operating system and the type of DSO or executable that should be built. The "library" of templates used by Cutter can be accessed via the main menu bar at,
    Templates->Bat
and
    Templates->Makefiles


Step 1 - User supplied Makefiles / VS .bat files?

Before using a template, Cutter checks if the user has supplied their own Makefile or VS .bat file. For example, suppose a file named "myImplicit.cpp" is executed, Cutter will search the parent directory in order to find, depending the operating system, a script named,
    Makefile.myImplicit (OSX and Linux),
or
    Build_myImplicit.bat (Windows).

If the file is found, Cutter searches it to see if its first comment begins with either,
    # Maintained by Cutter
or
    rem Maintained by Cutter

If the script is not "tagged" with this string, Cutter will consider it to be one that is "maintained" by the user and will not overwrite it. After performing this check, Cutter will proceed to run the script from the script's parent directory.


Step 2 - Templates & Placeholders

If Cutter is unable to locate a suitably named script, or it is tagged as one that is maintained by Cutter, a template will be used to generate a fresh version of the Makefile or VS .bat file. Initially, Cutter searches for a suitable template in the users
    custom_templates/Makefile
or
    custom_templates/Bat
directory. If a user-template is not found, Cutter will use one of its own default templates. Once a suitable template has been found it is copied to the directory in which the users 'C/C++' source code is located. During this process Cutter searches for "placeholders" within the body of the template. These are either replaced with specific strings (generally derived from Preferences) or, if a substitution string is not available, the "placeholder" is deleted.


Placeholder

Substitution derived from

  _DEVKIT_PATH_
  _IMPLICIT_PLUGIN_NAME_
  _OTHER_INCLUDE_DIRS_
  _OTHER_LIB_DIRS_
  _OTHER_LIBS_
  _OTHER_OBJS_
  Prefs->devkit->path
  Name of the source file
  Prefs->"include" dirs
  Prefs->"include" dirs
  Prefs->.lib
  Prefs->.o (see below)

Step 3 - Custom Templates

Users can ensure the makefiles and VS .bat files generated by Cutter are based on their custom templates. The easiest way to accomplish this is to make a copy of the default template that is relevent to the type of plugin or executible the user is developing. For example, if a user is developing some shadeops on Linux they could,

  1. locate a file named Makefile.shadeo_LINUX - it can be found in
        Cutter_Help/templates/Makefiles
  2. copy it, without changing its name, to
        custom_templates/Makefiles
  3. edit the text of Makefile.shadeo_LINUX -
        perhaps to add extra compiler/linking flags.

Thats all there is to it. Thereafter, Cutter will generate specific makefiles derived from the custom makefile template.


Multiple Source Files

Suppose "myImplicit.cpp" also uses a class or classes implemented in a file named "MyUtils.cpp". In other words a successful build of the DSO depends on compiling and linking more than one source code file. Cutter determines what "extra" objs to add to the Makefile by examining the list of #include's at the top of the main file. For example, upon finding, say,

    #include "MyUtils.h"

Cutter will search the directory in which "myImplicit.cpp" is located in order to find a file named either "MyUtils.cpp" or "MyUtils.c". If it finds either file it will append the following line in the Makefile,

    OBJS = myImplicit.o MyUtils.o

A similiar logic is used to modify the text of a VS .bat file.




© 2002- Malcolm Kesson. All rights reserved.