Re: Building Subversion DLLs

On 12/8/05, Branko Čibej <brane@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 12/6/05, Branko Čibej <brane@xbc.nu> wrote:
> >
> >> Ivan Zhakov wrote:
> >>
> >>> On 12/6/05, Branko Čibej <brane@xbc.nu> wrote:
> >>>
> >>>
> >>>> libsvn_subr.def:
> >>>>
> >>>> ...
> >>>> EXPORTS
> >>>> ...
> >>>> svn_ctype_table DATA
> >>>> ...
> >>>>
> >>>> No source-level decoration is necessary.
> >>>>
> >>>>
> >>> Yes, but in this case *some* test fails! I can't figure why. But if
> >>> declare svn_ctype_table with __declspec(dllexport) everything works
> >>> OK.
> >>>
> >>>
> >> Now, that _is_ funny. I wonder what's going on...
> >>
> > I have discovered problems:
> > http://msdn2.microsoft.com/en-us/library/619w14ds.aspx
> > In a few words: On Windows exporting variable means exporting
> > *pointer* to this variable and importing must dereference it.
> > __declspec(dllexport)/__declspec(dllimport) makes this automatically.
> > So I see several ways:
> > 1. Use __declspec(dllimport) for variables only. Causes special define
> > for *each* dll to separate dll building dll from importing.
> > 2. Use __declspec(dllimport) everywhere on windows -- anyway causes
> > usage special define per library and change signature of all API.
> >
> Not really... only when you link with a DLL, and since we don't provide
> DLLs yet, it's not actually a signature change. :)
>
> > 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?

--
Ivan Zhakov