SCL Files for Dynamic Loading

If you generate a dynamic-linked library containing implementations of SIDL classes, you must also generate a SIDL Class List file (SCL file). An SCL file contains metadata about zero or more dynamic-linked libraries; for each dynamic-linked library, the SCL file has the list of SIDL classes implemented in that library. The sidl.Loader.findLibrary method searches SCL files when trying to find the implementation (or some other aspect) of a SIDL class.

The SCL file is an XML file with three kinds of elements. The top level element is scl which contains zero or more library elements. The library element has several attributes, and it contains zero or more class elements. The library element has three required attributes, uri, scope and resolution, and two optional attributes, md5 and sha1. The uri is a local filename including path or a network url indicating where the library is stored. The scope attribute allows developers to suggest whether the library should be loaded in a local or the global namespace. The developer can suggest lazy or now symbol resolution using the scope attribute. The md5 and sha1 are optional message digests to confirm that the library has not been modified or replaced. The class element has two required elements, name and desc. The name field is the name of the class, and desc indicates what kind of information is held in the library. Each class contained in the dynamic-linked library should be listed in the SCL file. For now, the only desc values with standardized meanings of ior/impl, java and python/impl. ior/impl indicates the dynamic-linked library contains the IOR object and implementation for the class, and java indicates that the library has the Java JNI wrapper object code. python/impl has the Python skeletons and implementation libraries.

Here is an the SCL file for the SIDL runtime library installed in /usr/local.

<?xml version="1.0" ?> 
<scl>
  <library uri="/usr/local/lib/libsidl.la" scope="global" resolution="now" > 
    <class name="SIDL.BaseClass" desc="ior/impl" />
    <class name="SIDL.ClassInfoI" desc="ior/impl" />
    <class name="SIDL.DLL" desc="ior/impl" />
    <class name="SIDL.Loader" desc="ior/impl" />
    <class name="SIDL.Boolean" desc="java" />
    <class name="SIDL.Character" desc="java" />
    <class name="SIDL.DoubleComplex" desc="java" />
    <class name="SIDL.Double" desc="java" />
    <class name="SIDL.FloatComplex" desc="java" />
    <class name="SIDL.Float" desc="java" />
    <class name="SIDL.Integer" desc="java" />
    <class name="SIDL.Long" desc="java" />
    <class name="SIDL.Opaque" desc="java" />
    <class name="SIDL.SIDLException" desc="ior/impl" />
    <class name="SIDL.String" desc="java" />
  </library>
</scl>
It's worth noting that the uri can be a libtool metadata file (.la) when the library is located on the local file system or a dynamic-linked library file (.so or another machine dependent suffix). You cannot have a libtool .la when the library is remote (e.g., ftp: or http:) because libtool expects the files references in the .la file to be local and in particular directories.

The GNUmakefile generated with the --makefile Babel option contains rules to automatically generate .scl files for each of the supported Babel languages.



babel-1.4.0
users_guide Last Modified 2008-10-16

http://www.llnl.gov/CASC/components
components@llnl.gov