> > > 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.
bye,
Erik.
Received on Thu Dec 8 14:43:30 2005