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

Auth providers and problems with our packaging

From: Ben Reser <ben_at_reser.org>
Date: Fri, 14 Jun 2013 13:21:13 +0200

Starting with 1.4 but particularly in 1.6 we started adding platform
specific authorization providers. This is a good thing because it
allows us to use platform specific authorization stores.

However, there have been some unintended consequences of the way we
implemented these. Specifically we hid these APIs and constants
related to them in our header files behind conditionals. This means
we don't have a consistent API.

The problem is that we generate SWIG files and ship them in our
tarballs. Since the header files are conditional based on platform,
SWIG will possibly see interfaces that will not be available on the
users platform. This is particularly noticeable when the tarballs are
produced on some platform other than the Mac and then someone tries to
build the SWIG bindings on the Mac. E.G.

[[[
[breser_at_kong subversion-1.8.0]$ make swig-py
/bin/sh /Users/breser/subversion-1.8.0/libtool --tag=CC --silent
--mode=compile llvm-gcc-4.2 -pipe -g -O2 -DDARWIN
-DSIGPROCMASK_SETS_THREAD_MASK
-I/Users/breser/subversion-1.8.0/subversion
-I/Users/breser/subversion-1.8.0/subversion/include
-I/Users/breser/subversion-1.8.0/subversion/bindings/swig
-I/Users/breser/subversion-1.8.0/subversion/bindings/swig/include
-I/Users/breser/subversion-1.8.0/subversion/bindings/swig/proxy
-I/Users/breser/subversion-1.8.0/subversion/bindings/swig/proxy
-I/usr/include/apr-1 -I/usr/include/apr-1
-I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
-I/Users/breser/subversion-1.8.0/subversion/bindings/swig/python/libsvn_swig_py
-prefer-pic -c -o subversion/bindings/swig/python/core.lo
subversion/bindings/swig/python/core.c
subversion/bindings/swig/python/core.c:3851: error: expected
declaration specifiers or '...' before
'svn_auth_gnome_keyring_unlock_prompt_func_t'
subversion/bindings/swig/python/core.c: In function
'svn_auth_set_gnome_keyring_unlock_prompt_func':
subversion/bindings/swig/python/core.c:3853: error:
'SVN_AUTH_PARAM_GNOME_KEYRING_UNLOCK_PROMPT_FUNC' undeclared (first
use in this function)
subversion/bindings/swig/python/core.c:3853: error: (Each undeclared
identifier is reported only once
subversion/bindings/swig/python/core.c:3853: error: for each function
it appears in.)
subversion/bindings/swig/python/core.c:3854: error: 'prompt_func'
undeclared (first use in this function)
subversion/bindings/swig/python/core.c:3855: error:
'SVN_AUTH_PARAM_GNOME_KEYRING_UNLOCK_PROMPT_BATON' undeclared (first
use in this function)
subversion/bindings/swig/python/core.c: In function
'_wrap_svn_auth_set_gnome_keyring_unlock_prompt_func':
subversion/bindings/swig/python/core.c:32568: error:
'svn_auth_gnome_keyring_unlock_prompt_func_t' undeclared (first use in
this function)
subversion/bindings/swig/python/core.c:32568: error: expected ';' before 'arg2'
subversion/bindings/swig/python/core.c:32581: error: 'arg2' undeclared
(first use in this function)
subversion/bindings/swig/python/core.c:32587: error: too many
arguments to function 'svn_auth_set_gnome_keyring_unlock_prompt_func'
make: *** [subversion/bindings/swig/python/core.lo] Error 1
]]]

When we first did this in 1.4 by adding the support for the Mac
keychain support this wasn't noticed because we probably never
generate packages from the Mac and if you generate the packages on
some other *nix then the pre-generated SWIG bindings simply lack the
keychain support on the Mac. Had we produced packages from the Mac
then all the other *nix would have had seen a similar problem.

We can safely exclude APIs based on being on Windows since we do not
ship pre-generated SWIG bindings for Windows and we cannot produce
packages on Windows. However, we cannot do this with any *nix
platform unless we want to be shipping broken pre-generated SWIG
files.

I propose we stop hiding APIs based on platform. APIs that return an
svn_error_t should return a new NOT_IMPLEMENTED error code. APIs that
do not (as is the case with the auth APIs in this case) should provide
some appropriate noop behavior. In the case of
svn_auth_get_*_provider APIs should return a noop provider (which at
current we don't have) but shouldn't be hard to provide.

This will allow us to provide generated SWIG bindings that work across
the various Unix platforms.
Received on 2013-06-14 13:21:52 CEST

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.