[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SWIG and platform-specific auth providers (Was: Python bindings build seems broken)

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: Mon, 3 Nov 2008 00:12:29 -0700

Hi Jeremy,

On Wed, Oct 15, 2008 at 3:29 PM, Jeremy Whitlock <jcscoobyrs_at_gmail.com> wrote:
> Hi All,
> There have been some notable changes to how SWIG handles
> platform-specific auth providers over the last few days. As of
> r33671, we now have a very versatile solution that should completely
> get rid of auth provider related segfaults in the SWIG bindings and
> make it easier for people to write in platform-specific auth support
> into their SWIG binding based Subversion applications.
> As of r33671, you will have all platform-specific auth providers
> wrapped by SWIG, regardless of your operating system. (Or so it
> seems.) The way this works is we use some nice SWIG magic to get SWIG
> to wrapper a function but at compile time, if the function should not
> be available based on platform or missing functionality, the
> Subversion-specific function is excluded from the C file and instead,
> a SWIG exception is thrown in its place. So instead of the function
> not being wrapped at all, to SWIG users, it "appears" to be wrapped.
> What this means is when you attempt to call
> "core.svn_auth_get_keychain_simple_provider" while on Windows, instead
> of getting a "Symbol not found error" or some segfault, you get this
> nice RuntimeError that you can handle gracefully. If you don't
> believe me, check out
> subversion/bindings/swig/python/tests/auth.py(test_conditional_auth_provider_support).
> In that test, we attempt to get the simple provider for keychain,
> windows, gnome-keyring and kwallet all without conditionally calling
> those functions based on operating system. :)
> This was done without any core Subversion modification other than
> exposing the platform-specific auth functions to SWIG. That's it.
> And the "magic" I mentioned earlier really isn't magic but using SWIG
> to either wrap the function or pretend to wrap the function. When it
> pretends to wrap, you have a language-specific RuntimeException
> thrown. Now, the way we do this is with this cool little SWIG macro
> in subversion/bindings/swig/include/svn_global.swg. What this does is
> allow you to specify a function, tell what #ifdef should be used to
> allow that function to be compiled into SWIG's core.c and then SWIG
> handles the rest. The reason I'm telling you this is because this
> macro might be useful to other non-auth Subversion functions that
> happen to be platform-specific and desirable to be wrapped by SWIG.
> Here is some pseudo code to explain how core.c might look based on
> whether a function is wrapped or not:
> *_wrap_svn_auth_get_keychain_simple_provider(PyObject
> *SWIGUNUSEDPARM(self), PyObject *args) {
> .....
> svn_auth_get_keychain_simple_provider(arg1,arg2);
> #else
> SWIG_exception(SWIG_RuntimeError,
> "'svn_auth_get_keychain_simple_provider' is not available on this
> platform.");
> #endif
> ...
> }
> So if the system compiling core.c has Keychain services,
> svn_auth_get_keychain_simple_provider is compiled into _core.so,
> otherwise, you get an exception at runtime in its place. Since the
> actual Subversion symbol is conditionally compiled in, that means that
> while you may have core.svn_auth_get_keychain_simple_provider
> available to Python, the actual svn_auth_get_keychain_simple_provider
> symbol does not need to exist in libsvn_subr-1.dylib. That lets you
> actually call that on any system and handle the result appropriately.
> --
> Take care,
> Jeremy Whitlock
> http://www.thoughtspark.org

Slick idea. After r33671 and r33707 I'm still having a bit of trouble with the
Ruby bindings. I think the issue is that SWIGWIN is defined empty when the
PLATFORM_SPECIFIC_WRAPPER macro is expanded by SWIG, so I ended up with a
#ifdef with no macro to test the definition of when trying to actually compile
the bindings.

Attached is a patch that uses a new macro SVN_SWIG_WINDOWS that is not defined
when PLATFORM_SPECIFIC_WRAPPER is expanded, and then is defined later. Does
this sound reasonable? Is there a better name for the new macro? Is there a
better place for it to be defined?

Joe Swatosh

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org

Received on 2008-11-03 08:12:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.