4 ==> For instructions on how to get swig bindings working, read the
5 INSTALL file in this directory.
8 SVN HEADER -> SWIG MODULE
9 -------------------------
11 Subversion has a bunch of include files, some which are interesting for
12 wrapping with language bindings, and others which are simple type
13 declarations and constants. Below is the table which maps each header
16 INCLUDE SWIG MODULE NAME
17 svn_auth.h _core (some symbols)
21 svn_config.h _core (some symbols)
27 svn_error_codes.h _core
30 svn_io.h _core (only stream functions)
32 svn_opt.h _core (some symbols)
33 svn_path.h _core (some symbols, 1)
34 svn_pools.h _core (only pool manipulation)
35 svn_props.h _core (some symbols)
44 svn_time.h _core (some symbols)
47 svn_version.h _core (some symbols)
53 (1) It is assumed that the binding languages will provide this
54 functionality separately.
55 ### HELP: Java does not provide base-64 natively. Should we wrap
56 ### SVN's with SWIG, or include a stand-alone ASF implementation
57 ### (such as from Jakarta Commons Codec)?
59 (2) No significant/interesting functionality to export.
61 (3) A SWIG interface file exists, but only to export types used by other
62 modules. No binding module is actually constructed from this
69 We will produce a number of modules/classes, expecting the binding
70 languages to organize these into a package, and present the Subversion
71 libraries' API in a manner familiar to programmers of a given
72 language. For instance, the Python bindings are handled as follows:
88 "Thunk" is Windows programming term describing a "go between." Our
89 SWIG bindings generally implement editors in C which delegate to the
90 language-specific extension API (e.g. its C API for Python, JNI for
91 Java, etc.). This transitional object implements a Subversion editor
92 interface, allowing it to be passed between its native library code
93 and the runtime of the language which the bindings were written for.
98 SWIG INTERFACE FILE CODING NOTES
99 --------------------------------
101 Always place %{ #include "foo.h" ... %} sections above any code which
102 will actually cause SWIG to generate wrappers. This is because those
103 wrappers may need declarations from the headers to be valid C.
104 Practically, this means that the %{ ... %} block should be above any
105 "%include *.h" statements (%includes of *.i files are fine, since they
106 should be self-sufficient).