From: Nitro <ni...@dr...> - 2008-01-30 00:29:24
|
Am 29.01.2008, 17:42 Uhr, schrieb William S Fulton <ws...@fu...>: > I've got a similar problem. I have a few hundred .i files and each one > corresponds to a separate invocation of swig and each has a unique > module name. > I'd like to put all the modules in one package as suggested here. I > don't mind > shipping a few hundred .py files, but I would rather not build a few > hundred > .pyd files (dlls). How can I get each of the individual modules to call > the > appropriate init function when loaded, but for it to know to find the > init > function in a single common dll (.pyd)? Is this possible? First I think this is not easily possible. Maybe doing it with -interface command line switch might work if there aren't multiple init functions with the same name defined. You'd probably have to fight linker/runtime issues, not sure. Probably needs some experimentation with two simple .i files for testing. Second I don't think it's desirable. If you generate a wrapper for each .i file and later compile all into a single dll you'll end up with build time issues sooner or later. Every time you modify one of the .i files (or underlying headers), the whole .pyd will have to be rebuild. I guess the modules are not independent from each other so you'll need %import too. In my project I do it like this: I have a bunch of higher level modules like Math, Physics, Core etc.. Each of these has a master .i file which %includes a bunch of other .i files (for example the Math.i would %include Matrix.i and %include Vector.i and so on). Now say Math is dependent on the Core module. Then I'll add an %import Core.i at the top of Math.i . What I end up with are like 10 modules (Math, Physics, Core...), one dll and one .py file for each. This is a good compromise between build speed, dependency management and user friendliness. -Matthias |