On 8/27/05, Branko Èibej <brane@xbc.nu> wrote:
> The Python bindings on HEAD of trunk don't compile on windows. Part of
> this seems to be a bug in the runtime generator:
>
> Compiling...
> swigutil_py.c
> ..\..\..\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(1313) : warning C4003: not enough actual parameters for macro 'SWIG_GetModule'
> ..\..\..\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(1319) : warning C4003: not enough actual parameters for macro 'SWIG_GetModule'
These warnings look like they were caused by a SWIG bug. The
SWIG_GetModule macro is defined as follows by SWIG 1.3.25 on my
machine:
#define SWIG_GetModule(clientdata) SWIG_Python_GetModule()
Later in the file, SWIG uses the SWIG_GetModule macro as a zero-argument macro:
swig_module_info *module = SWIG_GetModule();
GCC parses the above as follows:
swig_module_info *module = SWIG_Python_GetModule();
Can Microsoft Visual C++ handle the above code? You said that Visual
C++ reports warnings; does the code still work? If not, I can modify
our runtime generator to work around this SWIG bug.
> The other issue seems to be s SWIG problem:
>
> Performing Custom Build Step on ..\..\..\subversion\bindings\swig\core.i
> C:\Home\brane\src\svn\httpd-2.0.54\srclib\apr\include\apr.h(326): Error: Syntax error in input.
>
>
> This is the offending line in apr.h:
>
> typedef unsigned __int64 apr_uint64_t;
It looks like SWIG can't handle the __int64 type. Perhaps we can fool
SWIG by defining __int64 to "long long".
Try this patch:
[[[
subversion/bindings/swig/proxy/apr_h.swg:
Workaround SWIG bug which means that SWIG cannot parse "__int64",
by defining "__int64" to be "long long".
]]]
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 27 23:41:36 2005