[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.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.