Copyright (C) 2000-2012 |
GNU Info (g-wrap.info)CaveatsCaveats ======= 1. I'd like to state right up front that g-wrap is to some extent an experimental work. It seems useful, but it is certainly not elegant, at least not yet, and maybe not ever, and it's somehat hard for me to say whether that's a statement about the problem, or the current solution. 2. The current implementation of the wrapper types (normal, non-native, and enumerations), and the whole "hash-table" oriented infrastructure behind them should almost certainly be re-written reasonably soon to use goops instead of the ad-hock mess that's there right now which somewhat fakes a mini-inheritance structure. None of this has any effect on wrapper run-time, but it's ugly. 3. G-wrap should be made smarter about guile modules. In particular it needs to be migrated away from the old (and deprecated) way of implementing use-modules completely in one .so file. Making this change will involve switching g-wrap to generate a .scm file *and* a .so. Once that's done, perhaps we should allow for the specification of scheme code that should be inserted into places in the parent .scm file (This might eliminate the need for many uses of the gw:inline-scheme function, or perhaps better yet, we should figure out a way to orient g-wrap much more closely toward generating *just* the C wrappers and let the user create the top-level .scm file themselves. I'm not sure that would retain all the flexibility, but it would simplify things, and I already worry that g-wrap is suffering from mission-creep. 4. All of these things are my (rlb's) fault, not Christopher's :> automatically generated by info2www version 1.2.2.9 |