On 2019/09/19 8:21, Johan Corveleyn wrote:
> On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej <brane_at_apache.org> wrote:
>>
>> On 18.09.2019 09:20, Johan Corveleyn wrote:
>>> On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej <brane_at_apache.org> wrote:
>>>> On 18.09.2019 02:48, Johan Corveleyn wrote:
<snip>
>>>>> [[[
>>>>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
>>>>> definition in parentheses
>>>>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
>>>>> ]]]
>>>> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
>>>> this on line 123:
>>>>
>>>> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
>>>>
>>>>
>>>> Looks like perfectly valid C to me. So we'll need a bit more context to
>>>> see where the actual error is coming from.
>>> Not at my pc right now (I'll check again tonight), but from memory: I
>>> think my copy of pytime.h looks the same. Line 123 seems to be the
>>> first usage of 'timeval' though ... Is it possible that some include
>>> is missing, so there is no declaration of the timeval struct type?
>>
>>
>> You do *not* need a definition of 'struct foo' in order to use a 'struct
>> foo*' pointer. So, no, that's not the problem.
Actually C4115 is only a warning.
https://docs.microsoft.com/cpp/error-messages/compiler-warnings/compiler-warning-levels-1-and-4-c4115?view=vs-2019
However, it seems we are treating it as an error by specifyinging build
option in build/generator/templates/vcnet_vcxproj.ezt .
(Is it related to https://bugs.python.org/issue25878, especially
msg256496 ?)
<snip>
> In other news, building the swig-py3 branch (after sync-merge from
> trunk) with Python 2.7.16 (and swig 3.0.12) was successful.
> Running the testsuite gives some failures though:
>
> [[[
> Testing Release configuration on local repository.
> -- Running Swig Python tests --
> ..............s..............EE........F....F...........................................................................
> ..................................
> ======================================================================
> ERROR: test_conflict (client.SubversionClientTestCase)
> Test conflict api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 593, in test_conflict
> conflict = client.conflict_get(trunk_path, self.client_ctx, pool)
> File "R:\test_release--swigpython\swig\pylib\libsvn\client.py", line
> 1642, in svn_client_conflict_get
> return _client.svn_client_conflict_get(*args)
> SubversionException: 155007 - 'R:\temp\tmpyeizeh-conflict\trunk' is
> not a working copy
>
> ======================================================================
> ERROR: test_conflict (client.SubversionClientTestCase)
> Test conflict api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 94, in tearDown
> self.temper.cleanup()
> File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\utils.py",
> line 44, in cleanup
> clean_func(target)
> File "R:\test_release--swigpython\swig\pylib\libsvn\core.py", line
> 8453, in svn_io_remove_dir
> return _core.svn_io_remove_dir(*args)
> SubversionException: 720032 - Can't remove
> 'R:\temp\tmpyeizeh-conflict\.svn\wc.db'
> 720032 - Can't remove file 'R:\temp\tmpyeizeh-conflict\.svn\wc.db':
> The process cannot access the file because it is being used by another
> process.
>
> ======================================================================
> FAIL: test_merge_peg3 (client.SubversionClientTestCase)
> Test svn_client_merge_peg3.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 442, in test_merge_peg3
> self.assertEqual(readme_text, b'This is a test.\n')
> AssertionError: 'This is a test.\r\n' != 'This is a test.\n'
>
> ======================================================================
> FAIL: test_shelf (client.SubversionClientTestCase)
> Test shelf api.
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
> line 644, in test_shelf
> self.assertIn(new_subpath, statused_paths)
> AssertionError: 'trunk\\new-shelf-test.txt' not found in
> ['trunk/new-shelf-test.txt', 'trunk/new-shelf-test.txt', None]
>
> ----------------------------------------------------------------------
> Ran 153 tests in 38.984s
>
> FAILED (failures=2, errors=2, skipped=1)
> Exception svn.core.SubversionException: SubversionException("Can't
> open file 'R:\\temp\\tmp9ubdal-client\\db\\fs-type':
> The system cannot find the path specified. ", 720003) in <bound
> method Temper.__del__ of <utils.Temper object at 0x02B8B4F0>> ignored
> [Test runner reported failure]
> ]]]
>
> (Running the swig-python tests on trunk, with Python 2.7.16, was fully
> successful)
>
The FAIL on test_merge_peg3 is a newline style issue on reading file
in raw mode, which is introduced by my patch.
(https://svn.apache.org/viewvc/subversion/branches/swig-py3/subversion/bindings/swig/python/tests/client.py?view=annotate#l438)
Rest of those errors and failures are in the tests that were added only
to swig-py, and it seems most of the causes of them are confusion of
paths in platform specific format and Subversion's canoical format,
as the comment in SubversionClientTestCase.test_update4() says.
(I'll try to fix those issues on check-swig-py later, hopefully
next weekend.)
--
Yasuhito FUTATSUKI
Received on 2019-09-19 08:45:17 CEST