On 12/6/05, Branko Čibej <brane@xbc.nu> wrote:
> Ivan Zhakov wrote:
> > On 12/5/05, Max Bowsher <maxb1@ukf.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Erik Huelsmann wrote:
> >>
> >>> Hi!
> >>>
> >>> Yesterday, Zhakov started working on building Subversion DLLs. We
> >>> fixed up extractor.py to return exported variables as well as public
> >>> functions from our headers.
> >>>
> >>> Most tests complete successfully, but some don't. It looks like that's
> >>> because svn_ctype_table isn't declared __declspec(dllexport). To make
> >>> that declaration platform independent, we could include
> >>> APR_DECLARE_DATA into the definition of svn_ctype_table. I think this
> >>> is the right way to go, but Ivan said it's for internal use by APR (to
> >>> declare APR data, but not for use by applacations-using-apr..).
> >>>
> >>> Can someone comment on this issue?
> >>>
> >> Yes. You cannot use APR_DECLARE_DATA, because that will expand to
> >> __declspec(dllimport). It only expands to __declspec(dllexport) when
> >> inside the compilation of APR itself.
> >>
> >> If you wanted to go down this route, you would need to define a
> >> SVN_DECLARE_DATA, which varied depending on whether you were compiling
> >> _Subversion_, not APR.
> >>
> > To be accurate: we should define macro for each dll, so it would be
> > SVN_LIBSVNCLIENT_DATA, SVN_LIBSVN_DELTA_DATA for example.
> >
> Yes. This kind of clutter is one of the reasons for my -1 to such
> decorations unless they're absolutely necessary.
> >> However, I thought the whole point of extractors and .def files was to
> >> avoid decoration?
> >>
> > There is another problems with extractors not counting data exports:
> > there are functions that not applicable for windows, keychain auth
> > provider for example, so we need some way to exclude it from .def
> > files.
> >
> So what? If we do have platform-specific public APIs (which, IMHO, we
> shouldn't have), then extractor.py can jolly well learn about #ifdef.
I don't like platform-specific public APIs also, but have such one
(svn_auth_get_keychain_simple_provider). Of course we can teach
extractory.py for #ifdef but it too complex for me :)
>
> >> If it turns out that .def files cannot adequately support data exports,
> >> I think we would be better off just to use decoration everywhere - using
> >> one system for function exports and a different system for data exports
> >> would be too confusing.
> >>
> > I'll continue investigation of this problem today, but I can belive
> > that we will be must use decoration for data exports.
> >
> 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.
>
> >>> Also, in APR, all functions are declared using APR_DECLARE(type).
> >>> We'll be using extractor.py and accompanying .def file to export our
> >>> functions (in order to export with index-numbers). Strictly speaking,
> >>> in this situation it's not necessary anymore to use APR_DECLARE. Will
> >>> we need to start using APR_DECLARE for other reasons?
> >>>
> >> AFAIK, the only other cause to use a declaration macro is if you need to
> >> decorate to force calling convention (i.e. APR_DECLARE_NONSTD).
> >> I'm not aware of us forcing any calling conventions at present.
> >>
> > For me it is good practice to specify calling conventions when
> > declaring dll exports. Because it could be imported by different
> > compiler, with different default calling convetion settings.
> >
> On Windows, the default calling convention for DLL-exported functions is
> well defined. I couldn't care less about compilers that don't follow
> even the (admittedly spottily) documented standards of the OS they're
> supposed to generate code for.
Thanks, I didn't know this.
--
Ivan Zhakov
Received on Tue Dec 6 11:20:03 2005