[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] libsvn_swig_ruby as dll for windows builds

From: Joe Swatosh <joe.swatosh_at_gmail.com>
Date: 2007-01-16 00:43:41 CET

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

This is an archived mail posted to the Subversion Dev mailing list.