[Ben Reser]
> Actually now that I think about it a bit more I'm not sure that
> helps. It'll probably just shift it to a link time error because the
> defines will be there so it'll build, SWIG will generate wrappers for
> them that depend on the functions in our libraries, which won't be
> available in the libraries they built because we exclude them on
> their platform.
Oh man. What a horrible API. All this time I had assumed that this
was a plugin system, such that the only bit of code that really had to
talk to libsvn_auth_* was a handful of functions in libsvn_subr.
Everyone else would call those with a standard interface. Neither SWIG
nor anything else outside libsvn_subr would need to know anything about
which plugins had been compiled.
How did we get to a point where the SWIG-based bindings (and, by
implication, third-party scripts) actually have to know how to talk to
specific auth plugins? Or, to ask it another way, how did
plugin-specific stuff ever end up in a public header? I suppose it's
far too late to fix that now, but....
Received on 2013-06-19 10:09:52 CEST