You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2003/03/19 11:24:26 UTC
[PATCH] non static libs on windows (dll)
Hi,
To use subversion as a dll and not as a statically linked library
some code changes needed to be made which are included in
this patch. For *NIX there is no change at all.
I followed the approach APR uses for that so I hope it's
alright.
Please note that for the statically linked libs the *.dsp's for
the client(s) now need the preprocessor SVN_DECLARE_STATIC set!
I don't have VC6 so I didn't mess around with those, the dsp for
the dll I created with this tool:
http://www.codeproject.com/tools/prjconverter.asp
Also, if the project is compiled to a dll then apr also needs to
be linked as a dll (use the aprlib*.dsp's for that).
Log-Message:
required changes to build subversion to a windows dll
* SubversionDLL.dsp VC6 project
* include/svn.h defines for SVN_DECLARE_xxx
* include/svn_auth.h changed the function declarations/definitions
include/svn_base64.h
include/svn_client.h
include/svn_config.h
include/svn_delta.h
include/svn_diff.h
include/svn_error.h
include/svn_error_codes.h
include/svn_fs.h
include/svn_hash.h
include/svn_io.h
include/svn_md5.h
include/svn_opt.h
include/svn_path.h
include/svn_pools.h
include/svn_props.h
include/svn_quoprint.h
include/svn_ra.h
include/svn_ra_svn.h
include/svn_repos.h
include/svn_sorts.h
include/svn_string.h
include/svn_subst.h
include/svn_test.h
include/svn_time.h
include/svn_types.h
include/svn_utf.h
include/svn_version.h
include/svn_wc.h
include/svn_xml.h
libsvn_auth/auth.c
libsvn_client/add.c
libsvn_client/auth.c
libsvn_client/cat.c
libsvn_client/checkout.c
libsvn_client/cleanup.c
libsvn_client/commit.c
libsvn_client/copy.c
libsvn_client/delete.c
libsvn_client/diff.c
libsvn_client/export.c
libsvn_client/log.c
libsvn_client/ls.c
libsvn_client/prop_commands.c
libsvn_client/resolve.c
libsvn_client/revert.c
libsvn_client/status.c
libsvn_client/switch.c
libsvn_client/update.c
libsvn_client/url.c
libsvn_delta/cancel.c
libsvn_delta/default_editor.c
libsvn_delta/diff.c
libsvn_delta/diff_file.c
libsvn_delta/svndiff.c
libsvn_delta/text_delta.c
libsvn_fs/deltify.c
libsvn_fs/fs.c
libsvn_fs/id.c
libsvn_fs/revs-txns.c
libsvn_fs/tree.c
libsvn_fs/txn.c
libsvn_fs/uuid.c
libsvn_ra/ra_loader.c
libsvn_ra_dav/session.c
libsvn_ra_local/ra_plugin.c
libsvn_ra_svn/client.c
libsvn_ra_svn/editor.c
libsvn_ra_svn/marshal.c
libsvn_repos/checkout.c
libsvn_repos/commit.c
libsvn_repos/delta.c
libsvn_repos/dump.c
libsvn_repos/fs-wrap.c
libsvn_repos/load.c
libsvn_repos/log.c
libsvn_repos/node_tree.c
libsvn_repos/reporter.c
libsvn_repos/repos.c
libsvn_repos/rev_hunt.c
libsvn_subr/cmdline.c
libsvn_subr/config.c
libsvn_subr/config_file.c
libsvn_subr/error.c
libsvn_subr/getdate.y
libsvn_subr/hash.c
libsvn_subr/io.c
libsvn_subr/md5.c
libsvn_subr/opt.c
libsvn_subr/path.c
libsvn_subr/pool.c
libsvn_subr/quoprint.c
libsvn_subr/sorts.c
libsvn_subr/stream.c
libsvn_subr/subst.c
libsvn_subr/svn_base64.c
libsvn_subr/svn_string.c
libsvn_subr/target.c
libsvn_subr/time.c
libsvn_subr/utf.c
libsvn_subr/validate.c
libsvn_subr/xml.c
libsvn_wc/adm_crawler.c
libsvn_wc/adm_files.c
libsvn_wc/adm_ops.c
libsvn_wc/copy.c
libsvn_wc/diff.c
libsvn_wc/entries.c
libsvn_wc/lock.c
libsvn_wc/log.c
libsvn_wc/merge.c
libsvn_wc/props.c
libsvn_wc/providers.c
libsvn_wc/questions.c
libsvn_wc/status.c
libsvn_wc/status_editor.c
libsvn_wc/translate.c
libsvn_wc/update_editor.c
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Branko Cibej wrote:
>
>
>>...
>>
>>
>>>3) All exported functions should use plain data types or struct
>>>pointers. If a typedef or #define to wrap the plain types is
>>>necessary, it sure should be clearly unique to the library so there
>>>is no chance of a name collision.
>>>
>>>
>>>
>>You're mixing two things here: one is an ABI issue (like 2), the other
>>is a naming convention issue. We don't have naming convention
>>problems.
>>
>>
>
>What is the ABI issue? I can't see a problem with using typedefs.
>
I read (3) as forbidding passing struct params by value. That's the ABI
issue.
>>>5) Due to the madness of windows memory management in a DLL system,
>>>I should never directly free something the dll allocated or vice
>>>versa, except via calls into the library for this express purpose.
>>>
>>>
>>>
>>Yet another ABI issue, although in this case, the shot is at
>>Microsoft, not at everybody else. Berkeley DB is the only library
>>that has explicit problems with this, but our other libraries are
>>also vulnerable. I think we'll simply have to provide two versions of
>>the libraries in the development package, and they'll have to have
>>different names.
>>
>>
>
>If you are writing new code, it's much easier to follow the guideline and
>just not call malloc() and free() for a given block of memory across shared
>libaries.
>
Well, we're not writing new code, we're using existing code (Berkeley DB
in this case).
>I don't think microsoft has made any mistakes here. Unlike unix, windows has
>no special relationship with C. malloc and free are not syscalls, so you
>shouldn't assume that every library can call them directly.
>
Malloc and free aren't syscalls, they're C runtime functions even on
Unix. They're usually implemented in terms of brk, sbrk, mmap of valloc
(which _are_ syscalls), but that doesn't change things. Changing the
heap layout *and* the library name was a stupidity, plaing and simple.
If they'd kept the same library name for the basic C runtime,
dynamically linked prigrams would just use the right malloc and free
everywhere. Statically linked programs don't have a problem anyway.
>APR really shouldn't be pulling in windows.h in its public headers either,
>although I see that it does do this in apr.h ...
>
>
I'm afraid it has to. Otherwise the error handling stuff just wouldn't work.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
>> 1) All exported functions have their calling convention defined in
>> the prototype. My project settings might not match the setting the
>> library was built against for this.
>>
> That, I'm afraid, is a valid point. I'm still looking for the bright
> guy at MS who decided that mixinc calling conventions is a good
> thing. I've even got several different kinds of pincers warming in
> the coals.
>
Heh. Maybe you can get him to settle on one bawling convention...
> ...
>> 3) All exported functions should use plain data types or struct
>> pointers. If a typedef or #define to wrap the plain types is
>> necessary, it sure should be clearly unique to the library so there
>> is no chance of a name collision.
>>
> You're mixing two things here: one is an ABI issue (like 2), the other
> is a naming convention issue. We don't have naming convention
> problems.
What is the ABI issue? I can't see a problem with using typedefs.
>> 5) Due to the madness of windows memory management in a DLL system,
>> I should never directly free something the dll allocated or vice
>> versa, except via calls into the library for this express purpose.
>>
> Yet another ABI issue, although in this case, the shot is at
> Microsoft, not at everybody else. Berkeley DB is the only library
> that has explicit problems with this, but our other libraries are
> also vulnerable. I think we'll simply have to provide two versions of
> the libraries in the development package, and they'll have to have
> different names.
If you are writing new code, it's much easier to follow the guideline and
just not call malloc() and free() for a given block of memory across shared
libaries.
I don't think microsoft has made any mistakes here. Unlike unix, windows has
no special relationship with C. malloc and free are not syscalls, so you
shouldn't assume that every library can call them directly.
>> 6) Pulling in loads of system headers due to including the library
>> headers can be annoying, but sometimes unavoidable. A lot of
>> standard library functions are unsafe (and banned in some shops) and
>> people tend to use whats in the address space accidentally
>> (sprintf/strcat etc come to mind). Pulling in windows.h is fat and
>> slow and should be avoided at all costs.
>
> We don't (or at least, we shouldn't) use the unsafe functions; I think
> we're pretty disciplined in that respect. OTOH, what's "banned in some
> shops" doesn't concern me at all -- we only export the SVN API,
> nothing else, and we use the safe APR versions of the string
> functions everywhere.
>
> We do pull in windows.h (as part of APR if nothing else), but it's
> pared down to a minimum (by defining WIN32_LEAN_AND_MEAN). I don't
> think we include windows.h from any of our public headers directly.
APR really shouldn't be pulling in windows.h in its public headers either,
although I see that it does do this in apr.h ...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
seanc@dimensionalrift.com wrote:
>Just a minor interjection: as a user of third party libraries, I expect
>the following things to be true of any library, for it to be considered
>'nice and well behaved':
>
>1) All exported functions have their calling convention defined in the
>prototype. My project settings might not match the setting the library
>was built against for this.
>
That, I'm afraid, is a valid point. I'm still looking for the bright guy
at MS who decided that mixinc calling conventions is a good thing. I've
even got several different kinds of pincers warming in the coals.
>2) All exported data structures are wrapped with #pragma pack's, for the
>same reason.
>
Sorry, but that's nonsense. The system ABI defines the layout of
structs. Compilers that don't conform to the ABI don't interest me at all.
>3) All exported functions should use plain data types or struct pointers.
> If a typedef or #define to wrap the plain types is necessary, it sure
>should be clearly unique to the library so there is no chance of a name
>collision.
>
You're mixing two things here: one is an ABI issue (like 2), the other
is a naming convention issue. We don't have naming convention problems.
>4) Exported data structures should never contain an enum type. An int or
>similar type is far superior.
>
Again, another ABI issue.
>5) Due to the madness of windows memory management in a DLL system, I
>should never directly free something the dll allocated or vice versa,
>except via calls into the library for this express purpose.
>
Yet another ABI issue, although in this case, the shot is at Microsoft,
not at everybody else. Berkeley DB is the only library that has explicit
problems with this, but our other libraries are also vulnerable. I think
we'll simply have to provide two versions of the libraries in the
development package, and they'll have to have different names.
>6) Pulling in loads of system headers due to including the library
>headers can be annoying, but sometimes unavoidable. A lot of standard
>library functions are unsafe (and banned in some shops) and people tend to
>use whats in the address space accidentally (sprintf/strcat etc come to
>mind). Pulling in windows.h is fat and slow and should be avoided at all
>costs.
>
We don't (or at least, we shouldn't) use the unsafe functions; I think
we're pretty disciplined in that respect. OTOH, what's "banned in some
shops" doesn't concern me at all -- we only export the SVN API, nothing
else, and we use the safe APR versions of the string functions everywhere.
We do pull in windows.h (as part of APR if nothing else), but it's pared
down to a minimum (by defining WIN32_LEAN_AND_MEAN). I don't think we
include windows.h from any of our public headers directly.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by se...@dimensionalrift.com.
> On Saturday, March 22, 2003, at 06:10 PM, Russell Yanofsky wrote:
>
>>> 4) Exported data structures should never contain an enum type. An
>>> int or similar type is far superior.
>>
>> Yes. I don't know whether subversion does this.
>
> not being a windows person, i have no idea why using enumerated types
> would be a problem. what exactly is the issue with this? i've always
> been told to prefer enums for reasons of type safety.
>
The size of an enum varies from compiler to compiler, and according to
the language only needs to be as large as to contain any of the enum
values correctly. With VC an enum is always an int, but it shouldn't be
assumed. The following enum might end up being a char for instance:
enum foo
{
booga=0,
wooga=1,
};
This is one reason why many of MS's enums in DirectX for example all have
dummy values at the end of the enum like this:
typedef enum _D3DCULL {
D3DCULL_NONE = 1,
D3DCULL_CW = 2,
D3DCULL_CCW = 3,
#if(DIRECT3D_VERSION >= 0x0500)
D3DCULL_FORCE_DWORD = 0x7fffffff, /* force 32-bit size enum */
#endif /* DIRECT3D_VERSION >= 0x0500 */
} D3DCULL;
I wish someone would change the langauge standards so you could specifiy
which data type an enum should use . . .
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
mbk@boredom.org wrote:
>On Sat, Mar 22, 2003 at 06:14:46PM -0500, Garrett Rooney wrote:
>
>
>>On Saturday, March 22, 2003, at 06:10 PM, Russell Yanofsky wrote:
>>
>>
>>
>>>>4) Exported data structures should never contain an enum type. An
>>>>int or similar type is far superior.
>>>>
>>>>
>>>Yes. I don't know whether subversion does this.
>>>
>>>
>>not being a windows person, i have no idea why using enumerated types
>>would be a problem. what exactly is the issue with this? i've always
>>been told to prefer enums for reasons of type safety.
>>
>>-garrett
>>
>>
>>
>
>Some compilers generate smaller-than-int storage allocations for enums
>with less than MAXINT values. They then proceed to, for example, char
>align them. This can cause headaches.
>
>
I couldn't care less about compilers that don't follow the system's ABI.
On Windows, VC++ sets the (C) ABI [1], and other compilers have to
follow that. We're not going to support noncompliant compilers.
[1] Note that I'm not talking about C++ here, just C
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by mb...@boredom.org.
On Sat, Mar 22, 2003 at 06:14:46PM -0500, Garrett Rooney wrote:
> On Saturday, March 22, 2003, at 06:10 PM, Russell Yanofsky wrote:
>
> >>4) Exported data structures should never contain an enum type. An
> >>int or similar type is far superior.
> >
> >Yes. I don't know whether subversion does this.
>
> not being a windows person, i have no idea why using enumerated types
> would be a problem. what exactly is the issue with this? i've always
> been told to prefer enums for reasons of type safety.
>
> -garrett
>
Some compilers generate smaller-than-int storage allocations for enums
with less than MAXINT values. They then proceed to, for example, char
align them. This can cause headaches.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
SteveKing wrote:
>>> 5) Due to the madness of windows memory management in a DLL
>>> system, I should never directly free something the dll allocated or
>>> vice versa, except via calls into the library for this express
>>> purpose.
>>
>> Subversion does not do this with the dlls it uses, and it would be
>> nice if it did. This is the reason we have to use different berkeley
>> db binaries for vc6 and vc7.
>
> That's not correct. The reason why there are different dll's for VC6
> and VC7 for the berkeley db is that VC7 uses a newer version of the
> C-runtime library.
> And according to MSDN these versions are not compatible, i.e. can't
> be used both from the same process.
> And since subversion also uses functions from the C-runtime lib (e.g.
> stdout)
> there must therefore also be two versions of the subversion dll.
>
I wasn't able to find any information on MSDN on this topic, but one of the
microsoft developers who worked on the C runtime explained the issue in
detail in some usenet posts:
http://groups.google.com/groups?selm=OeXwcqd2BHA.1288%40tkmsftngp07
http://groups.google.com/groups?selm=eFQ%23lcp2BHA.2112%40tkmsftngp02
It is perfectly ok to have many runtime libraries in the same process. There
are many situations where this can happen on windows. Different compilers
like borland, metrowerks, and cygwin's provide their own C runtimes, and
Visual C++ provides multiple runtimes (statically linked and dynamically
linked, single-threaded and multithreaded, debug and release). They can all
coexist.in one process because C runtimes are just plain old libaries on
windows, just optional wrappers over the win32 API.
One consequence of this is that calls to functions like malloc() can do
completely different things depending on what module (dll or exe) they take
place in and what runtime library the module is linked with. So you can't
malloc() some memory in dll A and free() it in dll B unless you can
guarantee that both DLLs are linked with the same runtime library. Because
subversion does do this with the berkeley db, it crashes when the berkely db
is linked with a separate runtime library. What Sean describes is good
practice that would have prevented this problem.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by SteveKing <st...@gmx.ch>.
> > 5) Due to the madness of windows memory management in a DLL system, I
> > should never directly free something the dll allocated or vice versa,
> > except via calls into the library for this express purpose.
>
> Subversion does not do this with the dlls it uses, and it would be nice if
> it did. This is the reason we have to use different berkeley db binaries
for
> vc6 and vc7.
That's not correct. The reason why there are different dll's for VC6 and VC7
for the berkeley db is that VC7 uses a newer version of the C-runtime
library.
And according to MSDN these versions are not compatible, i.e. can't be used
both from the same process.
And since subversion also uses functions from the C-runtime lib (e.g.
stdout)
there must therefore also be two versions of the subversion dll.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Saturday, March 22, 2003, at 06:10 PM, Russell Yanofsky wrote:
>> 4) Exported data structures should never contain an enum type. An
>> int or similar type is far superior.
>
> Yes. I don't know whether subversion does this.
not being a windows person, i have no idea why using enumerated types
would be a problem. what exactly is the issue with this? i've always
been told to prefer enums for reasons of type safety.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
seanc@dimensionalrift.com wrote:
> Just a minor interjection: as a user of third party libraries, I
> expect the following things to be true of any library, for it to be
> considered 'nice and well behaved':
>
> 1) All exported functions have their calling convention defined in
> the prototype. My project settings might not match the setting the
> library was built against for this.
This is a pretty good point. I'm not sure why anyone would change the
default calling convention, but if they did, they wouldn't be able to use
subversion's header files to call into the dll (At least not with Visual
C++, in Codewarrior you can say:
#pragma calling_convention(__cdecl)
#include "svn_whatever.h"
#pragma calling_convention(reset)
)
> 2) All exported data structures are wrapped with #pragma pack's, for
> the same reason.
This goes beyond "nice and well-behaved," it's downright charitable. The
windows header files don't even appear to do this.
If someone switches to a non default alignment they can be responsible for
writing:
#pragma pack(push, 8)
#include "svn_whatever.h"
#pragma pack(pop, 8)
in their own code.
> 3) All exported functions should use plain data types or struct
> pointers. If a typedef or #define to wrap the plain types is
> necessary, it sure should be clearly unique to the library so there
> is no chance of a name collision.
I get the part about using unique names, but don't see any problem with
using unnecessary typedefs or #defines. Both can be used to make code more
readable.
> 4) Exported data structures should never contain an enum type. An
> int or similar type is far superior.
Yes. I don't know whether subversion does this.
> 5) Due to the madness of windows memory management in a DLL system, I
> should never directly free something the dll allocated or vice versa,
> except via calls into the library for this express purpose.
Subversion does not do this with the dlls it uses, and it would be nice if
it did. This is the reason we have to use different berkeley db binaries for
vc6 and vc7.
> 6) Pulling in loads of system headers due to including the library
> headers can be annoying, but sometimes unavoidable. A lot of standard
> library functions are unsafe (and banned in some shops) and people
> tend to use whats in the address space accidentally (sprintf/strcat
> etc come to mind). Pulling in windows.h is fat and slow and should
> be avoided at all costs.
I don't think the subversion include files pull in any of these things. They
define platform-independent interfaces to the subversion libraries, so they
don't require windows type definitions or C string functions.
Also, I don't buy the whole "people tend to use whats in the address space"
argument. If a programmer writes some code that uses sprintf, and the
compiler gives an error saying sprintf is not defined, is he then going to
realize the error of his ways and rewrite the code? Most likely he'll just
go the top of the file and add #include <stdio.h>.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by se...@dimensionalrift.com.
Just a minor interjection: as a user of third party libraries, I expect
the following things to be true of any library, for it to be considered
'nice and well behaved':
1) All exported functions have their calling convention defined in the
prototype. My project settings might not match the setting the library
was built against for this.
2) All exported data structures are wrapped with #pragma pack's, for the
same reason.
3) All exported functions should use plain data types or struct pointers.
If a typedef or #define to wrap the plain types is necessary, it sure
should be clearly unique to the library so there is no chance of a name
collision.
4) Exported data structures should never contain an enum type. An int or
similar type is far superior.
5) Due to the madness of windows memory management in a DLL system, I
should never directly free something the dll allocated or vice versa,
except via calls into the library for this express purpose.
6) Pulling in loads of system headers due to including the library
headers can be annoying, but sometimes unavoidable. A lot of standard
library functions are unsafe (and banned in some shops) and people tend to
use whats in the address space accidentally (sprintf/strcat etc come to
mind). Pulling in windows.h is fat and slow and should be avoided at all
costs.
> [ hey russ! :-) ]
>
> On Fri, Mar 21, 2003 at 03:55:39AM -0500, Russell Yanofsky wrote:
>>...
>> Anyway, on the bigger issue I think the best alternatives are:
>>
>> 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.
>>
>> 2) Use __stdcall and __declspec() . The advantages are that __stdcall
>> function calls are smaller and faster than __cdecl calls, that explicit
>> __declspec(dllimport) declarations allow the compiler to further
>> optimise
>> calls (by eliminating a level of indirection), and that __stdcall is the
>> default calling convention for most languages other than C and C++, so
>> programmers using these languages wouldn't have to specify it explicity
>> or
>> wonder which convention to use.
>>
>> Either one seems reasonable to me...
>
> Since we can automate the first, and it is simplest for the developers,
> and
> the speed cost is negligible... we'll go with option #1.
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Greg Stein <gs...@lyra.org>.
[ hey russ! :-) ]
On Fri, Mar 21, 2003 at 03:55:39AM -0500, Russell Yanofsky wrote:
>...
> Anyway, on the bigger issue I think the best alternatives are:
>
> 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.
>
> 2) Use __stdcall and __declspec() . The advantages are that __stdcall
> function calls are smaller and faster than __cdecl calls, that explicit
> __declspec(dllimport) declarations allow the compiler to further optimise
> calls (by eliminating a level of indirection), and that __stdcall is the
> default calling convention for most languages other than C and C++, so
> programmers using these languages wouldn't have to specify it explicity or
> wonder which convention to use.
>
> Either one seems reasonable to me...
Since we can automate the first, and it is simplest for the developers, and
the speed cost is negligible... we'll go with option #1.
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
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
Steve King wrote:
>>Sorry, but that's not acceptable. Any patch that I'd consider for
>>inclusion must have the following characteristics:
>>
>> * It must be possible to create separate DLLs for each libsvn_*
>> library. If the patch also lets you build one huge DLL, that's
>> fine, but multiple DLLs is a prerequisite.
>>
>>
>
>Just ignore the *dsp the patch includes and change the
>library project to output a dll instead of a static lib and you're done.
>
Fine, so do it. :-)
>It's even easier to produce several dll's instead of a big one, but
>since I wanted that I included such a dsp file.
>
Well, we're moving towards a DSP generator. Maybe you could base your
patch on that -- teach the generator to make DLLs in addition to static
libs?
>
>
>
>> * It must introduce a DLL naming convention for:
>> o Debug vs. Release builds
>> o VC6 vs. VC7 builds
>>
>>
>I'm not sure what you mean about this. If you mean different
>names for each of those dll's
>
That's what I mean. For example, a Release DLL built by VC7 should have
a different name than a Release DLL built by VC6.
> then that can be done in the
>project files easily. Since I don't have VC6 I didn't touch those
>but someone with VC6 won't have any problems to do that.
>What I did was the 'big' work of changing all header and
>source files.
>
Unfortunately, that's not quite right because linkage between the DLLs
themselves won't be correct.
>> * It must not mandate the use of non-generated lists of exported
>> functions.
>>
>>
>It doesn't.
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Steve King <ic...@gmx.ch>.
> Sorry, but that's not acceptable. Any patch that I'd consider for
> inclusion must have the following characteristics:
>
> * It must be possible to create separate DLLs for each libsvn_*
> library. If the patch also lets you build one huge DLL, that's
> fine, but multiple DLLs is a prerequisite.
Just ignore the *dsp the patch includes and change the
library project to output a dll instead of a static lib and you're done.
It's even easier to produce several dll's instead of a big one, but
since I wanted that I included such a dsp file.
> * It must introduce a DLL naming convention for:
> o Debug vs. Release builds
> o VC6 vs. VC7 builds
I'm not sure what you mean about this. If you mean different
names for each of those dll's then that can be done in the
project files easily. Since I don't have VC6 I didn't touch those
but someone with VC6 won't have any problems to do that.
What I did was the 'big' work of changing all header and
source files.
> * It must not mandate the use of non-generated lists of exported
> functions.
It doesn't.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
SteveKing wrote:
>>Actually, if we're talking about making DLLs for each Subversion
>>library, there are quite a few of them, and there are many, many calls
>>across those APIs, between the libraries themselves. Still, the point
>>about modern hardware is a valid one.
>>
>>
>
>That would be one possibility. But I'd like to make one single dll where
>all the smaller libs are packed into.
>
>
Sorry, but that's not acceptable. Any patch that I'd consider for
inclusion must have the following characteristics:
* It must be possible to create separate DLLs for each libsvn_*
library. If the patch also lets you build one huge DLL, that's
fine, but multiple DLLs is a prerequisite.
* It must introduce a DLL naming convention for:
o Debug vs. Release builds
o VC6 vs. VC7 builds
* It must not mandate the use of non-generated lists of exported
functions.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by SteveKing <st...@gmx.ch>.
> Actually, if we're talking about making DLLs for each Subversion
> library, there are quite a few of them, and there are many, many calls
> across those APIs, between the libraries themselves. Still, the point
> about modern hardware is a valid one.
That would be one possibility. But I'd like to make one single dll where
all the smaller libs are packed into.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>cmpilato@collab.net wrote:
>
>
>>"SteveKing" <st...@gmx.ch> writes:
>>
>>
>>
>>>>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. 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?
>>>
>>>
>>I am nearly -1 on DEF files. Unnecessary maintainance burden.
>>
>>
>
>I don't see how DEF files are a maintenance burden. It's no more work put
>add a function to a DEF file than it is to add SVN_DECLARE to a source file.
>It's not like the DEF files will be able to go out of date with nobody
>noticing. If anything is wrong with the DEF files, there will be link
>errors.
>
>
Only if you use the DLLs. I would veto any use of DEF unless they are
dynamically generated from the sources as part of the build process.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
cmpilato@collab.net wrote:
> "SteveKing" <st...@gmx.ch> writes:
>
>>> 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. 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?
>
> I am nearly -1 on DEF files. Unnecessary maintainance burden.
I don't see how DEF files are a maintenance burden. It's no more work put
add a function to a DEF file than it is to add SVN_DECLARE to a source file.
It's not like the DEF files will be able to go out of date with nobody
noticing. If anything is wrong with the DEF files, there will be link
errors.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by cm...@collab.net.
"SteveKing" <st...@gmx.ch> writes:
> > 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. 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?
I am nearly -1 on DEF files. Unnecessary maintainance burden.
> What I don't quite get in this discussion is the part about speed. Todays
> computers are fast enough so that no one would ever notice the difference.
> There are no functions which are used multiple times, usually a client
> only calls one 'command' (like svn_client_update() or others) once and
> then the work is done inside the dll which takes the most time. So those
> few microseconds for the call itself really doesn't matter.
Actually, if we're talking about making DLLs for each Subversion
library, there are quite a few of them, and there are many, many calls
across those APIs, between the libraries themselves. Still, the point
about modern hardware is a valid one.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
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. 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?
You do not have to specify __cdecl in the source, it is the default calling
convention used in C and C++ code. The major advantage of this approach is
that you don't need to make *any* changes to the source, all you have to do
is write up a few DEF files and add them to the various projects.
> What I don't quite get in this discussion is the part about speed.
> Todays computers are fast enough so that no one would ever notice the
> difference. There are no functions which are used multiple times,
> usually a client only calls one 'command' (like svn_client_update()
> or others) once and then the work is done inside the dll which takes
> the most time. So those few microseconds for the call itself really
> doesn't matter.
I completely agree, and said that DLL performance issues shouldn't matter in
my first post. Greg and Branko both talked about these things, though, and I
wanted to provide some clarification. Basically, my conclusion was that
choice #1 allows for slightly faster loading time, and that choice #2 allows
for faster calls into the DLL.
> Also I would really like to have the patch applied so that we get the
> dll now. 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.
We don't need to wait for a DEF generator. Writing a def file is as easy as
adding macros to the sources. In fact, I volunteer to write the DEF files if
the subversion people decide to go this route. It won't take more than a few
hours of work since they can be based on your patch.
> 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?
Greg wanted to make one DLL for each library instead of one monolithic one
like libapr.dll, Branco said that the macro functions trip up doxygen, and
I've said that macro functions are unneccessary and ugly.
These are the reasons for wanting to take a different approach than APR. I
haven't heard any arguments for the APR approach...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>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.
>
Um. We don't have a 1:1 mapping between headers and libraries. So you'll
either have to supply a static mappng that tells you which headers
should be used to generate which DEF files, or you'll have to scan the
sources themselves to figure that out.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Greg Stein <gs...@lyra.org>.
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
Re: [PATCH] non static libs on windows (dll)
Posted by SteveKing <st...@gmx.ch>.
> 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. 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?
What I don't quite get in this discussion is the part about speed. Todays
computers are fast enough so that no one would ever notice the difference.
There are no functions which are used multiple times, usually a client
only calls one 'command' (like svn_client_update() or others) once and
then the work is done inside the dll which takes the most time. So those
few microseconds for the call itself really doesn't matter.
Also I would really like to have the patch applied so that we get the dll
now. 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.
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?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko Cibej wrote:
> Because the __declspec has to come before the type, and the __stdcall
> after the type.
Really? The following works for me on VC6
int __declspec(dllexport) __stdcall whatwhat()
{
return 0;
}
But you are right about __stdcall having to come after the return type, so
my example in the previous post couldn't work.
Anyway, on the bigger issue I think the best alternatives are:
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.
2) Use __stdcall and __declspec() . The advantages are that __stdcall
function calls are smaller and faster than __cdecl calls, that explicit
__declspec(dllimport) declarations allow the compiler to further optimise
calls (by eliminating a level of indirection), and that __stdcall is the
default calling convention for most languages other than C and C++, so
programmers using these languages wouldn't have to specify it explicity or
wonder which convention to use.
Either one seems reasonable to me...
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Branko Čibej <br...@xbc.nu>.
Russell Yanofsky wrote:
>Another place you might consider diverting from apr is in the use of
>function call macros. Why not use
>
> SVNAPI svn_error_t *
> svn_ra_init_ra_libs (void **ra_baton,
> apr_pool_t *pool)
>
>instead of
>
> SVN_DECLARE(svn_error_t *)
> svn_ra_init_ra_libs (void **ra_baton,
> apr_pool_t *pool)
>
Because the __declspec has to come before the type, and the __stdcall
after the type. And yes, we really do want to use __stdcall; most other
languages expect to use that by default when linking to DLLs. Only
variadic functions have to be declared __cdecl, and we have very few of
those.
Of course, we could just define STDCALL and CDECL, too.The real trouble
with all these macros is that they tend to get into the Doxygen docs;
that's why APR adds a @deffunc for every public function -- it can't
trust Doxygen to do the right thing in the presence of _DECLARE macros.
Regarding the generation and use of :DEF files:
* We don't want to export all funcitons with external linkage, only
the ones that are declared in headers in subversion/include. That
makes creating such a generator even harder.
* Dynamic loading with .DEFs is actually slower than with __declspec.
* Keeping the ordinals stable is possible, but you need the names
anyway if you want to do any dynamic loading (for mod_dav_svn, the
RA plugins, the future FS plugins, etc.)
Just adding some spice to the discussion... :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by Russell Yanofsky <re...@columbia.edu>.
SteveKing wrote:
>> * 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.
Like he said, if all functions use the default __cdecl convention then there
will never be any confusion about which convention to use, for example, when
writing local callback functions.
Another advantage of sticking with __cdecl is that if you do decide to use
DEF files, then you can eliminate the SVN_DECLARE macros.
I'm not sure about the compatibility with other languages. Delphi and Python
(ctypes module) support both calling conventions. I don't know about visual
basic.
>> * 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. :)
Another place you might consider diverting from apr is in the use of
function call macros. Why not use
SVNAPI svn_error_t *
svn_ra_init_ra_libs (void **ra_baton,
apr_pool_t *pool)
instead of
SVN_DECLARE(svn_error_t *)
svn_ra_init_ra_libs (void **ra_baton,
apr_pool_t *pool)
This is just an aesthetic issue, but it seems ugly to me to use function
call macros in function declarations.
>> 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.
You wouldn't need to wait for the tool. Its not any harder to maintain def
files by hand than it is to maintain SVN_DECLARE macros. On the other hand,
it doesn't really make sense to use def files unless you also switch to
__cdecl.
>> 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...
Some other performance-related issues are that using __stdcall instead of
__cdecl will reduce code size, and that adding __declspec(dllimport) can
make calls more efficient. I don't think any of this should really factor
into any decisions though.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] non static libs on windows (dll)
Posted by SteveKing <st...@gmx.ch>.
> 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
Re: [PATCH] non static libs on windows (dll)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Mar 19, 2003 at 12:24:26PM +0100, SteveKing wrote:
> Hi,
>
> To use subversion as a dll and not as a statically linked library
> some code changes needed to be made which are included in
> this patch. For *NIX there is no change at all.
Funny that you should send this. I was thinking about it on the drive into
work today :-)
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
* 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?"
* 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)
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?
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)
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.
Thoughts?
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