On Tue, Aug 13, 2024 at 10:34 PM Timofei Zhakov <t...@chemodax.net> wrote:
>
> On Tue, Aug 13, 2024 at 5:52 AM Jun Omae <jun6...@gmail.com> wrote:
> >
> > On 2024/08/09 6:41, Timofei Zhakov wrote:
> > > On Thu, Aug 8, 2024 at 9:44 PM <rin...@apache.org> wrote:
> > >>
> > >> Author: rinrab
> > >> Date: Thu Aug  8 18:44:01 2024
> > >> New Revision: 1919757
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1919757&view=rev
> > >> Log:
> > >> On the 'cmake' branch: Finally, support compilation of Python SWIG 
> > >> bindings.
> > >> ...
> > >
> > > Hi,
> > >
> > > Since this revision, the minimal SWIG bindings into Python can be
> > > successfully built. I didn't run any test program with the bindings
> > > compiled, but I think they should work, possibly requiring a few
> > > little fixes. I'd appreciate any help related to the bindings.
> > > Additionally, I will implement the compilation of the SWIG for Perl
> > > and Ruby soon (I had experimented with them in my working copy
> > > already, but didn't finish yet).
> > >
> > > Little note about compilation of the bindings: Currently, it's
> > > required to run the following commands before the build:
> > >
> > > $ python .\build\generator\swig\external_runtime.py .\build.conf swig 
> > > python
> > > $ python .\build\generator\swig\header_wrappers.py .\build.conf swig
> > >
> > > Otherwise, there will be a failure due to missing include files. In
> > > the feature these commands will be executed from somewhere else
> > > automatically. Also don't forget to enable the SVN_ENABLE_SWIG_PYTHON
> > > option.
> > >
> > > Thanks!
> > >
> > > --
> > > Timofei Zhakov
> >
> > I tried to build Python bindings and the building is done successfully.
> > However, I have two questions.
> >
> > 1.
> > *.pyd files are generated with "_python_<name>.pyd" named if building using 
> > cmake.
> > I think we must keep the file naming if no reasons between ./configure and
> > gen-make.py with/without cmake.
> >
> > Why?
> >
> > [[[
> > --- "trunk-py312\\subversion\\bindings\\swig\\python\\core.py"  2024-08-13 
> > 11:00:06.402495600 +0900
> > +++ "cmake-py312\\out\\core.py" 2024-08-13 11:09:02.361319300 +0900
> > @@ -27,7 +27,7 @@
> >
> >  _dll_paths = _dll_paths()
> >  try:
> > -    from . import _core
> > +    from . import _python_core
> >  finally:
> >      _dll_path = None
> >      for _dll_path in _dll_paths:
> > ...
> > ]]]
> >
> > 2.
> > I run build and install using cmake, however Python bindings are not
> > installed (libsvn_swig_py*.dll is installed but *.py and *.pyd files not).
> >
> > C> cmake -B %CD:\=/%/out -D CMAKE_INSTALL_PREFIX=%CD:\=/%/dist ...
> > C> cmake --build %CD:\=/%/out --target install ...
>
> Hi,
>
> The current naming exists there because I didn't customize their names
> yet and also if we set the same names they will collide with each
> other. I am currently trying to implement it in my working copy. I
> have a question related to it:
>
> I think that the bindings should be placed into the directory, to work
> from the build directory. I am looking for making the following layout
> of the files (taking Python swigs as an example):
>
> OUT/
>   libsvn_*
>   libsvn_swig_py.dll
>   PythonPackages/
>     libsvn/
>       _core.pyd
>       core.py
>       _client.pyd
>       client.py
>       [also some temporary files]
>       [maybe duplicate the libsvn_swig_py.dll here?]
>
> Are there any adjustments?
>
> However, it might not work correctly out-of-box, because when
> importing the _core.pyd library, it will not find the dependent DLLs.
>
> The installation is also not yet done, but it will be soon, with the
> correct names and build layout.
>
> Thank you for helping!

Hi again,

I am going to implement the following layout:

[[[
OUT/
  _client.pyd
  _core.pyd
  libsvn_subr-1.dll
  libsvn_client-1.dll
  libsvn_swig_py-1.dll
  PythonPackages/
    libsvn/
      core.py
      client.py
    svn/
      __init__.py
      core.py
      client.py
]]]

Here the _core.pyd and other binary modules will simply find the
dependencies from their directory, so there will not be any problems.

--
Timofei Zhakov

Reply via email to