From: John L. <le...@cs...> - 2006-01-25 01:40:19
|
On Tue, January 24, 2006 12:13 am, Marcelo Matus said: >>The simplest way to do this would be to add a %import "mod2.i" to the >>bottom of mod1.i. Then the mod1 type table correctly exports the >>connection between A and C. The only downside is it exports the type D >>too, making the module a little bit bigger.... but going back to a N log >> N >>importing makes this a small concern. If it was, we would just need to >>improve the detection that a type is not actually used anywhere, or add a >>%removetype D code or something. >> >> >> > the problem is, of course, you are asking the users to re-write the > interfaces in a smarter way > to overcome the runtime library features. the "mod" case is just a > simple example where human > intervention will be needed, and that is a very simple case. I still argue that import is correct solution. You are using a type in mod1, (namely C) without telling SWIG anything about it. In mod2, you are using a few types (A and B) without telling SWIG anything about it. I am not really seeing the difference between the two. For one case, we require import and for the other we don't? In theory, we could scrap %import completly, and merge all the type information at run-time... Actually with the change in swiginit.swg, I think you might be able to remove the import from mod2.i... except of course you get a warning mod2.i:3: Warning(401): Nothing known about base class 'B'. Ignored. Why should we ignore class 'B' in mod2.i, when we don't ignore class C in mod1.i? The reason we have %import in the first place is so SWIG knows all the type information about all the types used in the interface, and so that multiple interfaces don't mess with the types differently. It also allows more to be done at SWIG generation time and less at run time loading. I fail to see how adding one line to a bunch of interface files is a big deal... you can do it with a find | xargs echo ' ' >> if there are a lot of files, and if you have two mutually dependent modules I think each should import the other. If it is too much work, I think we should remove %import entirly. I think it should be both or none, why support one case of not telling SWIG enough information one way, and another case of not telling SWIG enough information another? > > Things can be a lot worse, for example, take a look at PyICU, they have > around > 10 modules and multiple cross imports, a lot of them to be specific. The > last swig version > that worked with PyICU was 1.3.24. With the last changes in the runtime > library PyICU is > working again, and no change was needed in the PyICU interfaces. And the > init time is really > neglectable. > > So, if you plan to play with the runtime library a little more, which I > welcome a lot, > at least we should establish a list of large "legacy" projects that > should keep running with no > extra human intervention, and since PyICU is a nice "multi-cross-import" > case, I propose it as the > first in the list. You can also use it also as a benchmark case to see > how fast the swig initialization > runs. I had a perl script that outputed C code with like 6000 classes A1, A2, etc. and I was using that to run tests... but if we could have a script that would download and run some big projects, that would be good. Something like writing a shell script to wget big projects, ./configure, make, make test or whatever. Could also use expect too. John |