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

Re: Building Subversion DLLs

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2005-12-08 14:40:54 CET

> > > 3. Never export/import data between libraries. I don't sure that this
> > > can be done.
> > >
> > I'd go with 3. Sure it can be done; in the few cases where we do have
> > public data items, we can deprecate those and create accessor functions
> > instead. It'll slow down a fiew things (notably the svn_ctype macros),
> > but I don't think the difference will be significant.
> >
> > I really hate the idea of per-library decorations because that would a)
> > complicate the build (we'd have to emit a different define when building
> > each library), b) it would reduce the readability of the public headers,
> > and c) it would mean that each library has to be built twice -- once as
> > a static lib, and once as a DLL -- instead of building just the static
> > lib, then simply relinking it as a DLL.
> Great, I like (3) too. I investigated svn_ctype used only in one place
> outside libsvn_subr: in libsvn_client for verifying prop_name. So we
> can add function like svn_xml_is_xml_name_valid() to libsvn_subr and
> call it from libsvn_client.
> But I see problem with compability: we had svn_ctype_table variable
> available, so If we strict we cannot remove it. Thoughts?

No need to remove it. Just deprecate it, introduce the new function
and don't export svn_ctype_table to the DEF file. We don't need to
support what we never released: since there were no DLLs before, we
won't be removing it from DLLs.


Received on Thu Dec 8 14:43:30 2005

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.