I wrote: > I also worry that the -Dinline approach could come back to haunt us if > the word inline was to appear in a header where it wasn't simply an > ignorable C keyword, eg; int inline_skating_shoes();, though I'll > concede this seems unlikely.
A baseless fear, as the pre-processor doesn't behave this way, this would only act on the inline keyword, or functions named "inline". On second thought, adding -Dinline doesn't sound like a bad idea, as its only downside is extra code, but on the upside it means less is required for other developers to get involved. I think that makes it worthwhile. Christian wrote: > We either need to upgrade this > (on trunk) to 1.3.31 or we need to add a workaround for versions lower > than 1.3.31, which would mean adding "-Dinline=" to SWIG_PYTHON_OPT. If we're going to do this, we shouldn't just add it to SWIG_PYTHON_OPT, but somewhere that will be used by all invocations of swig within GnuCash, as this isn't a swig -python specific problem. Someone else may wish to run gnc-numeric.h through swig sometime. (when they attempt to write Java bindings, *shudder*. ) Mark _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
