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).
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 12 12:48:54 2005