|
Harlequin RIP SDK
|
|
|
|
Harlequin RIP SDK
|
|
To integrate the Harlequin RIP SDK into your application, there are several libraries that must be linked with your code.
The core library is supplied as a dynamic-link library (corelib.dll on Windows, corelib.so on Linux, corelib.dylib on MacOS). There are a large number of entry points into the core library that the SDK and application layers use. While Global Graphics tries to keep this interface stable, the entry points that the SDK library uses do change over time. For this reason, Global Graphics recommends that the core library is linked at load time rather than at run time, so that explicit loading of all function addresses is not required.
The application may wish to alter the location where the dynamic library is loaded from. On Linux and MacOS the dynamic library paths can be set using -rpath or -Wl,-rpath linker directives. On Windows, this can be accomplished by delay-loading the core library. The "clrip" and "minrip" application layers delay-load the core library on Windows so the application can add the location of the core dynamic library to the PATH before the first function is called from it. The first function call to a delay-loaded library on Windows will load the dynamic library. The Visual Studio solution supplied by Global Graphics configures the "clrip" and "minrip" applications to delay-load corelib.dll. The nmake makefile supplied by Global Graphics delay loads corelib.dll using the linker directive /delayload:corelib.dll. The delayimp.lib helper library is needed to support delay-loading.
The Harlequin RIP SDK uses the Posix pthreads interface to provide cross-platform thread creation, mutexes, condition variables and thread-local storage. The Harlequin RIP SDK uses a subset of pthreads through a threading API (see Threads interface). The pthreads library must be linked with the application to provide the function calls needed.
On Linux and MacOS, pthreads is built into the operating system, and can be linked into the application by adding -lpthread to the application link command.
On Windows, Global Graphics uses the "Pthreads-win32" library to implement the Pthread interface. This is supplied in the distribution as the dynamic link library pthreads.dll. The SDK provides the function load_pthreads_dll() to explicitly load this library, and to read and store the required function addresses from it. load_pthreads_dll() is provided on Linux and MacOS too, but on those platforms it is a stub function that does nothing.
The pthreads library must be loaded before the Harlequin SDK or RIP are initialized.
The Harlequin SDK library is provided as source code, but also as a pre-built static library (hhrsdklib.lib on Windows, hhrsdklib.a on Linux and MacOS). Your application layer should be linked with this static library.
On Windows, the SDK library needs to be linked with the core library if it is built from source code.
The SDK library can alternatively be built as a dynamic library, but this option should not be used by customers without Global Graphics' approval. In particular, this is only suitable for RIPs secured using the "LDK" method, and not for RIPs secured using the "LE" method. If built as a dynamic library, the SDK library is named hhrsdkdll.dll on Windows, hhrsdkdll.so on Linux, or hhrsdkdll.dylib on MacOS. As with the core library, it is recommended that this is linked at load time, rather than at run time to avoid having to explicitly load every function address.
Your application layer should be linked with the dynamic core library, the static SDK library, and any other libraries the operating system requires.
On Linux, the "clrip" and "minrip" application layers require the addition libraries linked with -ldl, -lm, -lpthread, and -lrt.
On MacOS, the "clrip" and "minrip" application layers are linked with the Carbon framework, and the XCode MacOSX.sdk sysroot library.
On Windows, the "clrip" and "minrip" application layers require the additional Windows libraries advapi32.lib, dbghelp.lib, delayimp.lib, mscms.lib, netapi32.lib, psapi.lib, user32.lib, winspool.lib, and ws2_32.lib. Global Graphics recommends delay-loading the core library on Windows.
These libraries should be added to your application's linker command line, or added to your IDE as appropriate.
There is only one library you need to link to directly if you are integrating by linking your application to the Scalable RIP API. The Scalable RIP interface library is provided as a dynamic link library in the distribution (libripfarm.dll on Windows, libripfarm.so on Linux, libripfarm.dylib on MacOS). You may wish to delay-load this library on Windows, for the same reason as the core library is delay-loaded in the application layers. Delay-loading allows your application to change the location that the library is loaded from.
The libripfarm library will also load the additional libczmq and libjansson dynamic libraries, so these must be deployed in the same location as libripfarm is loaded from.
The Harlequin RIP includes some additional dynamic libraries to support Scalable RIP and other RIP functionality. These libraries must be installed in a location that the RIP can load them. The additional libraries are:
On Windows, most of these libraries are delay loaded by the core library, so need not be distributed if the functionality they provide is not used.