On 19/04/13 22:18, Jaren Johnston wrote:
> Hi William, thanks for taking a look.
>>> * director delegate - changed from public to internal
>> Okay. If you consider the delegate has an equivalent C pointer to function
>> a static global in the C++ wrapper file, it can also be viewed as
> 'internal' on
>> the C++ side.
> Ja, makes sense. Absolutely. I hadn't considered that though because I'm
> not using that interface. It's obviously a glue layer. I already have an
> existing C++ interface -- the one that I'm SWIGing. I would never invoke
> nor even look at the generated C++ wrapper, just as I would never use the
> PINVOKE interface directly. Is that really a thing? Do folks do that?
> I certainly could look at modifying the generation for it if so... but
> you'll have to let me know if that's actually useful. Not many spare cycles
>> When using %import and multiple assemblies, these have to be public.
>> See the SWIG_JAVABODY_ family of macros in java.swg.
> W/o having looked at the Java stuff, it sounds like C# has something
> similar. (I'm guessing ported.) I'm thinking of sec 19.7 in particular. I
> ran into the (in)visibility of getCPtr() before I started playing w/ the
> delegates, and one of the other recommended solutions worked for that.
> Namely, "the [assembly:InternalsVisibleTo("Name")] attribute".
Yup, that works too.
> Works well -- I'm using %import with multiple assemblies just fine. Public
> access not required.
> I'll take a look at the macro solution to see about extending that here. It
> *would* be nice to be consistent w/ the existing solutions.
>> A github patch would be preferred when you are finished as this runs all
>> C# tests on Travis (in case you can't run the test-suite from Windows). PS
>> can easily set up the Travis tests on your own github fork before
>> the patch.
> I don't know what "Travis" is, or how a "github patch" is different from a
> "git patch". A grep for "Travis" and "github" through the SWIG
> documentation and source turned up nil. (Well, Jon Travis turned up...)
> Googling "swig travis github" was not helpful. The patch I sent was against
> a clone from the repo hosted by github.
> Clearly, I'm a noob to your workflow. Would you be a dear and point me in
> the right direction?
Sorry, Travis is the CI system that will run the tests when you submit a
patch to github. Here are some pull requests checked on Travis:
https://travis-ci.org/swig/swig/pull_requests. A github patch is a git
patch submitted to github, our project on github is at
https://github.com/swig/swig and is the preferred, but not the only,
mechanism for providing patches. As you are most unlikely to get the
test-suite working on Windows, it is a good way to test/check your
patches if you only use Windows.