Hi kou,
On 1/5/07, Kouhei Sutou <kou@cozmixng.org> wrote:
> Hi,
>
> In <ae6cb1100701040740w7e291b6ld9a512b9e926950b@mail.gmail.com>
> "[PATCH] libsvn_swig_ruby as dll for windows builds" on Thu, 4 Jan 2007 07:40:22 -0800,
> "Joe Swatosh" <joe.swatosh@gmail.com> wrote:
>
> > * build.conf
> > for libsvn_swig_ruby set msvc-static to 'no' instead of 'yes'
>
> Applied.
>
>
> > * subversion/bindings/swig/ruby/test/run-test.rb
> > copy the libsvn_swig_ruby-1.dll to the ext directory for testing
> > add the ext directory to the path so libsvn_swig_ruby-1.dll can be
> > found to load
>
> Could you teach me that directory structure of build system
> on Windows?
>
> Do we need to setup ENV["PATH"]? Can we use $LOAD_PATH
> instead of ENV["PATH"]?
>
> > * subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.h
> > * subversion/bindings/swig/ruby/libsvn_swig_ruby/swigutil_rb.c
> > mimic the way that libsvn_swig_py causes its functions to be exported or not
> > for a windows build.
>
> Applied.
>
>
> Thanks,
> --
> kou
>
I am no expert on the build system, but here are my observations.
After generating the build files with the "python gem-make.py ...",
rebuilding Apache, I change directory to the working copy trunk an do
a build with "msdev subversion_msvc.dsw /USEENV /MAKE "__ALL_TESTS__ -
Win32 Release" where the Release part specifies a release build (could
be debug). After msdev has run, there is a Release subdirectory in
the working copy trunk. I them build the Perl, Python and Ruby
bindings with similar invocations of msdev. The Release directory
looks like this:
Release
mo
subversion
bindings
swig
perl
libsvn_swig_perl
native
perl_client
perl_core
perl_delta
perl_fs
perl_ra
perl_repos
perl_wc
python
libsvn_swig_py
python_client
python_core
python_delta
python_fs
python_ra
python_repos
python_wc
ruby
libsvn_swig_ruby
ruby_client
ruby_core
ruby_delta
ruby_fs
ruby_ra
ruby_repos
ruby_wc
libsvn_client
libsvn_delta
libsvn_diff
libsvn_fs
libsvn_fs_base
bdb
util
libsvn_fs_fs
libsvn_ra
libsvn_ra_dav
libsvn_ra_local
libsvn_ra_svn
libsvn_repos
libsvn_subr
libsvn_wc
mod_authz_svn
mod_dav_svn
reports
svn
svnadmin
svndumpfilter
svnlook
svnserve
svnsync
svnversion
tests
cmdline
getopt_tests_data
svnsync_tests_data
svntest
update_tests_data
libsvn_delta
libsvn_diff
libsvn_fs
libsvn_fs_base
libsvn_ra_local
libsvn_repos
libsvn_subr
With the build products of the various libraries in the similarly
named subdirectories. With the exception of the SWIG based bindings.
The dlls for the (perl|python|ruby)_client, perl|python|ruby)_core,
(perl|python|ruby)_delta, (perl|python|ruby)_fs,
(perl|python|ruby)_ra, (perl|python|ruby)_repos,
and(perl|python|ruby)_wc actually end up the the subdirectory under
swig that is the name of the language.
I hope this is more helpful than confusing.
To answer your explicit question above: Yes, we must modify the ENV['PATH'].
The reason is because libsvn_swig_ruby is now a dll instead of an
object library, the dlls with the bindings have to be able to load it
at run time using the typical, convoluted windows dll search rules.
So for example when we "require 'svn/ext/core" Ruby will find the
core.dll for us, but when Ruby causes windows to load it, windows
detects the dependency on libsvn_swig_ruby-1.dll and tries to load it.
This is the moment we need the svn/ext directory to be on the path so
windows can find it.
I've been playing around with some of this stuff, and I have a
different way of managing it that I think is a little more general.
If I can pull it together I will try to post patches in the next
couple of weeks.
I am sorry it has taken me so long to address your questions, I hope
this helps a little.
--
Joe Swatosh
Received on Tue Jan 16 00:43:50 2007