At this point, typing make should be enough to generate wrappers for your library.
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
If you are compiling your library with debugging enabled - ie, typing
make debug=yesthe 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.
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.
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.sobut if you compile it with debugging, it will be in the file
libgnustep-java_d.soBecause 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:
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