> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: donderdag 2 september 2010 2:16
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r991619 - in /subversion/trunk/subversion:
> include/private/svn_wc_private.h libsvn_client/commit.c
> libsvn_client/commit_util.c libsvn_client/merge.c libsvn_wc/entries.c
> libsvn_wc/node.c
>
> On Wed, Sep 1, 2010 at 13:44, <julianfoad_at_apache.org> wrote:
> >...
> > +++ subversion/trunk/subversion/include/private/svn_wc_private.h Wed
> Sep 1 17:44:41 2010
> > @@ -394,6 +394,7 @@ svn_wc__node_is_status_deleted(svn_boole
> > const char *local_abspath,
> > apr_pool_t *scratch_pool);
> >
> > +#if 0 /* not required with SINGLE_DB */
>
> Shouldn't this be #ifdef SVN_WC__SINGLE_DB ? I thought the idea was
> to keep using that define for a while so that developers can compile
> multi-db for testing purposes.
>
> Now... I recognize that symbol is not available to libsvn_client which
> then means that multi-db isn't possible any more? Maybe a more
> appropriate approach would be to just leave the functions as stubs?
> And then some ### markers to fully remove them when we strip out all
> the multi-db code? (in a couple weeks?)
Julian:
Any constructs like this break the shared library build on Windows.
We have a python script somewhere in the tree (extractor.py if I remember
correctly) that scans all the header files defined in build.conf to generate
.def files for the Windows DLLs. And these functions will be made public for
library users.
But in this case the scripts finds functions that aren't defined, but makes
them part of the public interface anyway. (Resulting in a linker error)
For a few specific cases (like mac only function) we applied some exceptions
to the extractor, but in this case I think we should just start removing
multi-db support.
Bert
Received on 2010-09-02 10:52:58 CEST