On Sat, Aug 10, 2024 at 10:26 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den tors 8 aug. 2024 kl 23:42 skrev Timofei Zhakov <t...@chemodax.net>: >> >> 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. >> > >> > * build/cmake/Findpy3c.cmake: New CMake module for the py3c library. >> > * build/generator/templates/targets.cmake.ezt >> > (swig.python): Add -nofastunpack option to Python SWIG compilation using >> > SWIG_COMPILE_OPTIONS target property. >> > * CMakeLists.txt >> > (python dependency): Rework finding of the package to request the >> > Development.Embed component if it is required by Python SWIG bindings. >> > (external-python): aAdd finding of py3c library, create the target with >> > correct include directories and link it against found py3c library. >> > >> > Added: >> > subversion/branches/cmake/build/cmake/Findpy3c.cmake >> > Modified: >> > subversion/branches/cmake/CMakeLists.txt >> > subversion/branches/cmake/build/generator/templates/targets.cmake.ezt >> [cut] >> >> 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. >> > Hi, > > On a cursory look, it looks great (unfortunately I run out of time tonight). > > Did you consider reporting the status of the bindings, something like this? > [[[ > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 1919798) > +++ CMakeLists.txt (working copy) > @@ -584,3 +584,6 @@ > message(STATUS " TODO: ......................... : Other dependecies") > message(STATUS " Bindings:") > message(STATUS " Build SVNXX ................... : ${SVN_BUILD_SVNXX}") > +message(STATUS " Build SWIG_PERL ............... : > ${SVN_ENABLE_SWIG_PERL}") > +message(STATUS " Build SWIG_PYTHON ............. : > ${SVN_ENABLE_SWIG_PYTHON}") > +message(STATUS " Build SWIG_RUBY ............... : > ${SVN_ENABLE_SWIG_RUBY}") > ]]]
Oh... I haven't done it yet. Would you like to go ahead and commit those? > (I'm not sure I understand if there is a reason why the variables (is that a > CMake term?) are named SVN_BUILD_xxx and SVN_ENABLE_xxx but I suppose these > should be reported under bindings). This is an interesting question. Initially, I was naming these options as SVN_BUILD_xxx. However, it doesn't make sense for some options, for example, SVN_BUILD_TESTS also enables the tests, so it is incorrect to name this option as they currently are. Additionally, I looked at the 'configure' script that has options like --enable-svnxx, --enable-javahl, --(disable|enable)-FEATURE, --enable-static, etc. I was thinking about fully renaming all SVN_BUILD_xxx options to SVN_ENABLE_xxx, but haven't done it... > I'm planning on spending tomorrow running test suites. Nice! I'll wait for your feedback. Thanks! -- Timofei Zhakov
