On 12/12/05, Branko Čibej <brane@xbc.nu> wrote:
> Erik Huelsmann wrote:
>
> >>>>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.
> >
> >
> Both of you are missing the point. The svn_ctype macros and functions
> are public. We can't remove them (and we should use them in more places
> anyway), so we must somehow export the svn_ctype_table. That means
> creating a public function that returns a reference to the table, not
> making the table private (and the public macros unusable).
The fact that the variable must be retrieved by a function makes in
private. That alone makes it a different interface from what we offer
on other platforms.
> Another thing: the fact that we've not yet released DLLs on Windows
> *does not* mean that we're free to offer a different API from DLLs than
> we do from static libs.
Sorry? We can't provide the API from dlls which we provide from static
objects: either they need an accessor function, or we need a -
currently not used - modifier. To me that sounds 'different'...
BTW: I never said we can't provide an accessor function, all I said
was we can't provide the direct access symbol (which is what you seem
to suggest too).
bye,
Erik.
Received on Mon Dec 12 18:44:43 2005