< 4.8 Useful Make Options when Creating Wrappers Next: 4.9 Including Special Code Up: 4. Wrapping Objective-C Libraries Previous: 4.7 The .jigs File

Subsections


4.8 Useful Make Options when Creating Wrappers

At this point, typing make should be enough to generate wrappers for your library.

4.8.1 Silencing the Wrapper Generator

By default, wrapper generation is quite verbose - it tells you exactly what it is doing - for example, it lists all the classes and methods which are being wrapped. If you find this annoying, you can turn it off by compiling with the verbose=no option, as in:

make verbose=no

4.8.2 Enabling Debugging

If you are compiling your library with debugging enabled - ie, typing

make debug=yes
the wrapper library will also be generated with debugging enabled. This means that the GNUmakefiles for the wrapping library will always automatically use debug=yes when the wrapping library is compiled. The wrapping code itself will be generated in the JavaWrapper_debug directory rather than in the JavaWrapper, to allow you to keep the two versions.

4.8.3 Debugging or Non-Debugging

When Objective-C GNUstep libraries are loaded from Java using JIGS, all the libraries must be of the same type - or debugging libraries or non-debugging libraries.

In general, the simplest way you can manage this issue is by consistently using only libraries of one of the two kind on your system; ie, compile everything (from the GNUstep Base Library up) with `make', or compile everything with `make debug=yes'.

If you don't, then you need to read carefully the following part.

4.8.3.1 The Fine Prints About Debugging

JIGS will decide whether to use debugging or non-debugging libraries at run-time, when it is first initialized from Java. Debugging libraries are easy to tell because the name ends with _d. For example, the core JIGS library is libgnustep-java; if you compile it without debugging, it will be in the file

libgnustep-java.so
but if you compile it with debugging, it will be in the file
libgnustep-java_d.so
Because the name is different, you can have both versions on your system. JIGS will choose to load debugging or non-debugging libraries in the following way:
  1. If you have only one version of JIGS installed (ie, only the debugging or the non-debugging, but not both), there is no choice - JIGS will load libraries of the same kind as itself. This means if you have a debugging version of JIGS installed, you will need to have a version of all libraries you need with debugging enabled. If you only have a non-debugging version of JIGS installed, you will need to have a version of all libraries you need without debugging.
  2. If you have both version of JIGS (the debugging and the non-debugging), JIGS will decide at run-time which version of itself to use (and consequently, which version of all other libraries to use). By default, it will load the non-debugging version. This is the default because the idea is that using a debugger to debug libraries when accessed from Java in this way is so difficult that most people will not want to do it (I actually don't know how to do it myself). But you can override the default by setting the JIGS_DEBUG environment variable. Setting it to YES or yes will give priority to the debugging libraries.
Once JIGS has chosen an option, it will follow it consistently. For example, if it decided to load debugging libraries, it will ignore all non-debugging libraries.

4.8.4 Turning off the Generation of Quick Reference Doc

To stop JIGS from automatically generating minimal javadoc comments and the quick reference documentation from them, it's enough to compile using javadoc=no, as in:

make javadoc=no


Next: 4.9 Including Special Code Up: 4. Wrapping Objective-C Libraries Previous: 4.7 The .jigs File
Nicola Pero 2001-07-24