We have used a modularized approached for an inhouse software, where C++
modules are compiled seperately. Some modules depends on others. Types from
these modules are %imported. We then glue everything together with a
centralized __init__.py file. SWIG's support for modules beeing part of a
larger package makes it even easier to create these sub-modules.
Hope this helped.
On Thursday July 8 2010 14:40:24 William S Fulton wrote:
> Daniel Blezek wrote:
> > William,
> > On 7/8/10 3:51 PM, "William S Fulton" <wsf@...> wrote:
> > > Daniel Blezek wrote:
> > >> We are currently considering revamping the support for ITK
> > >>
> > >> (www.itk.org) wrapping. One criticism of SWIG is the current
> > monolithic
> > >> wrapping paradigm. For instance, suppose we have 100 classes on one
> > >> module (not an unreasonable requirement). A single change in any
> > header
> > >> file requires regeneration of the SWIG output, which may take several
> > >> minutes to compile.
> > >>
> > >> Not being intimate with SWIG internals, could someone comment if
> > >> this
> > >>
> > >> approach would be feasible? We¹re not afraid to change or extend
> > >> SWIG, but don¹t want to head down a dead end.
> > >
> > > Have you looked at using %import and multiple modules (in the
> > > documentation)? Hopefully this meets your needs.
> > >
> > > William
> > Yes, I've been looking into this, and it is a good solution, but could
> > (potentially) result in a large number of modules. Ideally, we would
> > like only one module (or a few at minimum). At one extreme, you would
> > have a module for each wrapped class. At the other we have a huge .i
> > file that takes a long time to compile, and is regenerated every time
> > someone touches
> > a header file (which is where we are now).
> > We have debating working with SWIG to have it generate a snippit of
> > code for
> > each %import (or something like that). These snippits would be compiled
> > separately and linked into one big module. I don't know if this is at
> > all feasible, given how SWIG generates code, but it would be useful to
> > speed up
> > compilation of large modules. Then we could just lump our header files
> > inside SWIG and go.
> I don't know if there are any natural modules within ITK, but if there
> are, try and aim for this kind of modularisation with SWIG. I've found
> the modularisation a lot easier if you have a set of decent C++ modules
> that are built in layers on top of one another. Using one module per
> class results in quite a bit of duplicate code being generated and can
> bloat the binaries. Although -external-runtime can help alleviate this
> to some degree for the scripting languages. Beware mixing %import and
> %include of the same files, I've found strange behaviour when doing this
> and is something that SWIG ought to be modified to flag as a warning to
> the user.
> If I recall correctly ITK was using cable-swig due to various
> limitations in SWIG, is SWIG now okay for wrapping ITK, or are there
> still major problems?
> Once you have a number of modules, you might want to look at using
> ccache-swig in your build system to speed up invocations of SWIG where
> the inputs have not changed.
> --- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> Swig-devel mailing list