Erik Huelsmann wrote:
>>>- Compile everything yourself (which probably implies creating a
>>>Makefile based system which is Win32 compliant)
>>>
>>>
>>I thinks the Makefile based system is not such a problem. MSys should be
>>ok for that job.
>>
>>
>
>Currently we have a configure script which runs on many (all?) unix
>flavors, but has not been tested with any unix emulators on Windows.
>
>
It's supposed to work with Cygwin... not that that's much help.
>On windows we use gen_win.py from the root of the source tree.
>Currently it can't generate makefiles (because no-one ever wanted to
>compile with anything but MSVC.)
>
>
>
>>>- Enhance the build system so that we can generate DLLs so you can
>>>link against the dlls. This would help users of other languages too.
>>>(/me hopes this is a viable solution)
>>>
>>>
>>Thats a good idea. But! I have no idea how your build system works. Can
>>anybod give me some hints?
>>
>>
>If you want to know what to do in order to enable creation of DLLs,
>you can start by reading
>http://svn.haxx.se/dev/archive-2005-08/0319.shtml and
>http://svn.haxx.se/dev/archive-2003-10/0617.shtml . There's probably
>more in the archives. There might even be an issue in the issue
>database.
>
>Also, I'm cc-ing brane on this. He wants this to be done a long time
>already (but didn't have the time to do it). I hope brane and I can
>help you create a patch which will enable DLLs for Win32.
>
>
Here's how I would like to do it:
* First, teach the gen_win.py to change the names of all the
libsvn_* static libraries. Currently the static libarries are
called "libsvn_foo-m.lib", wher "m" is the svn major version (this
is the same as on Unix). I'd change that to "svn_foo-m.lib". These
new static lib projects should not have any library dependencies.
* Next, make generator create an additional project for each
libsvn_* library that creates libsvn_foo-m.n.{dll,lib,exp}, where
"m" is the major and "n" the minor version number -- these are the
DLL, the import library and the exported symbol library. The idea
is to simply take the svn_foo-m.lib static library and link it
into a DLL. These projects would depend on the static library, the
external libraries such as APR, and other Subversion DLLs. This
step requires a DEF file generator, which I believe has been 90%
done for ages.
* The unit test programs should link with static libraries, not the
DLLs, because they sometimes use private functions from the
library. We shouldn't export those from the DLLs, except in the
IIRC one case where we're cheating already.
* The projects for the command-line programs should come in two
flavours, statically and dynamically linked, so that people can
use the statically-linked versions for upgrades. Maybe it would be
enough to do this for svnadmin only, in which case I'd make it
statically linked to APR and BDB, too... well, we'll see.
The reason I'd like to rename the static libraries is to make SVN
consistent with APR on Windows (where you have the static
apr(_util)-m.lib and shared libapr(_util)-m.dll), and I think it makes
sense to encode both the major and minor version numbers in the DLLs,
because we need both to define the available set of APIs.
>>What i have to do so far:
>>I installed MSys + MinGW so i can use configure script in subversion
>>source. But it stops with
>>
>>/home/arichter/subversion-1.2.1/apr/configure:Error: decision on
>>anonymous shared memory allocation method failed
>>configure failed for apr
>>
>>No idea at the moment how i can fix this issue.
>>
>>
You'd have to fix the APR configury and teach it about MinGW/MSys first.
That's been on the APR wishlist for a long time, but I don't thing it's
simple to do.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 17 21:56:26 2005