Below is some text from the Apri 1996 monthly report that describes
integrating extensions
---start--
2.5 Third Party Extensions to Ptolemy

Motivated by interactions with Eric Pauer, of Lockheed/Sanders, and Fritz 
Heinrichmeyer, in Germany, we have begun a serious effort to ease the 
process of building and releasing third-party extensions to Ptolemy.  
Rather than having an ad hoc series of extensions with incompatible ways of 
integrating into Ptolemy, Christopher Hylands has proposed a more uniform 
solution.

  
  Extension Issues

     * The Ptolemy group really does not have the resources to fold all
       extensions into its releases. Also, not necessarily all extensions
       should be in UCB releases. Some extensions might be very
       experimental and unstable, or could be of interest to only a few
       Ptolemy users.  Some may be proprietary, or even classified.

      
     * Not all organizations can release software that has the UC
       Copyright. It is much easier for the Ptolemy group if most
       software in the release is covered by the UC Copyright. An
       exception is that we do distribute the GNU software which has a
       different copyright. However, if the Ptolemy group is to work on a
       file, that file should probably have the UC Copyright.

      
     * Not everyone can release source code for their extension. For
       debugging and support purposes, it is best if source code is
       available, but some organizations might not allow source code to
       be released.

         
  Approaches to External Extensions

The short-term solution is to create a standalone tar file that would 
produce libraries to build a pigiRpc with the extension.  Patching the 
Ptolemy tree directly is not very practical, since trying to include 
multiple extensions could cause no end of grief (Tcl has had a similar 
problem).

  
Eventually, we hope to be able to support Ptolemy extensions that are
shipped as libraries that can be loaded into a running pigiRpc. A
third party developer could provide shared libraries on their ftp site
without necessarily providing source code. Currently, there are a few
stumbling blocks with this method, but we hope to solve the shortly.

         
  Issues with incrementally linking of domains

   
Our ultimate goal is that a third party would be able to distribute domain 
libraries that would get linked in at run time.  Three problems arise with 
incremental linking that we will have to deal with.  First, many 
off-the-shelf incremental linking facilities do not work with C++ because 
static constructors do not get executed.  Second, incremental linking is 
very dependent on the compiler.  If someone were to make libraries 
available for incremental linking, they probably would have to have been 
built with the same compiler that was used to build the the Ptolemy 
executable.  Third, incremental linking of entire domains might not work on 
all platforms, or it might be too slow.  Currently, Ptolemy under 
SunOS4.1.3 uses ld to link in files, not dlopen() and shared libraries, as 
used in Solaris and HP/UX.       

  
  Extensions to be folded in to Ptolemy

In certain circumstances, a third party will have an extension that should 
be folded into an upcoming UCB release.  Usually we will only want to fold 
in an extension that we plan on using here at UC Berkeley.  In these cases, 
the files should have the UC Berkeley Copyright, although it would 
obviously attribute authorship.  The Ptolemy group at UC Berkeley would 
maintain the master source tree and the developers of the extension should 
provide changes to that tree.  Here at UCB, we port to a number of 
different platforms and compilers, and we often need to make minor 
modifications to the sources.

      
The original developers of the extension should probably obtain the 
Ptolemy prereleases and port any changes to that software.

      
In exchange for letting the Ptolemy group manage the master source tree, a 
developer gains our portability fixes and cleanups, and does not have to 
build standalone tar files.

--end--