swig/Examples/python/import_packages/split_modules
2016-06-02 22:45:59 -06:00
..
builtin split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
builtin_nopy3 split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
builtin_split split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
builtin_split_nopy3 split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
vanilla split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
vanilla_nopy3 split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
vanilla_split split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
vanilla_split_nopy3 split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
Makefile split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00
README split_wrapper -> split_modules to avoid conflict with clean rule 2016-06-02 22:45:59 -06:00

  These examples/tests are for when the swig generated wrapper module is split
between two packages.  Specifically the pure python part is part of a package
and the C/C++ part is not in any package at all.  Historically swig has
supported this sort of thing.


  The -builtin option is tested as well because additional import code
is generated by swig when it is used.  The builtin tests are for this
additional code in the python wrappers.

vanilla        # "plane Jane" module both halves in pkg1
vanilla_split  # python 1/2 in pkg1 C 1/2 in global namespace
builtin        # both halves in pkg1 (-builtin passed to swig)
builtin        # python 1/2 in pkg1 C 1/2 in global namespace (with -builtin)