> There are a couple problems with the approach in your patch, however:
>
> * each library needs its own set of macros so that libsvn_client.dll has
the
> correct linkage to functions in libsvn_subr.dll
why? I managed to compile, link and even use (with TortoiseSVN) the
resulting dll without any problems. Ok, I admit there were some problems
'cause some libraries have identical filenames like util.c which confuses
the
linker if those are linked together, but that's solved easily.
Oh, now I get it - you would compile each lib into an own dll? That's
possible now too without any problems.
But somehow I don't like to have several small dll's instead of one bigger -
it just takes longer to load them.
> * I'd prefer to avoid the "stdcall" stuff and just use C calling
conventions
> every where. it avoids a lot of questions with "should this be declared
> _NONSTD?"
yes, that would be the _NONSTD macro. But why don't you like the "stdcall"
approach? Other programming languages could use that better 'cause they
wouldn't need to convert to the C calling convention first before calling
functions
in the dll.
> * I don't think we want a header named "svn.h"; that feels just a bit too
> generic for something like this. Also, given that we'd have a full set
of
> macros for each library, the content will get pretty big. I'd suggest
> putting it into svn_types.h, or create svn__linkage.h or svn__declare.h
or
> something, and include that from each header.
> (users would never include the header)
I did that like apr did it. They too have one header file called apr.h and
that's
included in every other header file. That way users also never need to
include
that header. But I'm open about the name. :)
> All that said, I'd also like to investigate another approach. The DECLARE
> style macros are necessary to avoid .def files. However, what if we
> automatically generated .def files from the headers? That is, have the
> gen-make system create those files for us by analyzing the headers?
That would be very complicated to implement, would take a lot of time
and always include another step to get to the resulting dll. Sure, the
community
would love to have such a tool (search google and you'll find tons of
other people which need exactly such a tool), but since such a tool does
not exist yet I don't think we should block the subversion dll until there
is one. The benefit for clients in handling and size is IMHO just too
big to wait any longer.
> If we're smart, we might even be able to figure out a way to generate the
> .def files using ordinals rather than just names. ("smart" meaning to keep
> the ordinals stable)
/me dreaming about such a tool...
> It seems that I also recall hearing that ordinals might not be useful any
> more; that the runtime linkloader might be fast enough with names that the
> ordinal doesn't buy you much any more.
It depends on what language you use to call the functions. VB (some people
say that that is _not_ a programming language :) is AFAIK slower when
calling dll's with ordinals. I don't know about delphi or others...
Since I already compiled/linked the dll and used it I can tell that the size
of
the TortoiseSVN installer decreased about 900kb - and I think that the
subversion binaries would also get smaller. There are now three CL tools
which all are linked statically against the libs (svn.exe, svnlook.exe and
svnversion.exe)
so I think all those three together would get about 1400kb smaller in size.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 20 10:13:11 2003