On Fri, Mar 21, 2003 at 10:56:53AM +0100, SteveKing wrote:
> > 1) Use __cdecl and DEF files. The advantages are that it doesn't require
> any
> > modifications to the source, that it might lead to slightly faster load
> > times if ordinals are specified, and that __cdecl is the default calling
> > convention for C and C++, so programmers wouldn't have to specify it
> > explicity or wonder which convention to use.
>
> That would require extra work.
A miniscule amount, actually :-) I just checked in a module to extract
function names from our headers. It is important to note that our headers
are *very* regular, stylisticly, and all of our functions are properly
namespaced which makes them easy to find.
See build/generator/extractor.py. It produces a list that is *very* close.
There are only *seven* differences in the list produced by the extractor,
compared to the list produced by examining the symbols in the shared
libraries. I bet that I can eliminate most of those quite quickly (for
example, the declaration for svn_fs_is_txn_root is wrong -- it has too many
spaces before the open paren). If I can't eliminate the others
automatically, then I can just manually filter them.
> And I think that would lead to problems
> whenever the DEF file doesn't match the __cdecl in the source. Or can
> you guarantee that those are always in sync?
Guaranteed because we'll automate it.
> What I don't quite get in this discussion is the part about speed. Todays
Just a comment. Not a big deal. As you rightly point out, SVN is I/O bound,
so the clock cycle or three we spend doesn't really matter.
>...
> Also I would really like to have the patch applied so that we get the dll
> now.
Nope. We don't want one big DLL because that won't match everybody's usage.
For example, we don't want to include Berkeley DB references in there
because not everybody will want that. It is quite likely that DAV-only
clients will be built.
The patch also slams every header and almost every single file in the
distribution. I don't believe that we need to make a single change, so I'd
rather not even see that kind of disruption. The DEF file approach is also
*way* easier for developers, compared to the macro approach.
> If a def-file generator is planned or even already started then
> that could be changed again in the future. I just don't like to wait that
> long
> until we get the dll - the benefit of a smaller binary is IMHO too big to
> wait any longer.
Won't be long :-) The extraction is basically done. Now we just need a
little wrapper function to generate a .DEF file from the list of functions.
That is a teensy .ezt template.
> And I also don't understand quite the reason why we not want to do it
> the same way as apr does it. Subversion uses apr, apr works well. So
> what exactly is wrong with that approach?
Too complicated. In fact, I might even suggest using my extractor for the
APR projects :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 21 22:26:03 2003