On 26.10.2019 05:41, Daniel Shahaf wrote:
> Investigating this failure:
>
>
> /tmp/svn-dist/subversion-1.13.0//./subversion/tests/libsvn_subr/error-test.c:224:
> (apr_err=SVN_ERR_TEST_FAILED)
> svn_tests: E200006: Strings not equal
> Expected: 'ENOENT'
> Found: '(null)'
> at
> /tmp/svn-dist/subversion-1.13.0//./subversion/tests/libsvn_subr/error-test.c:224
> FAIL: error-test 3: test svn_error_symbolic_name
>
> The test code is in subversion/tests/libsvn_subr/error-test.c:
>
> 185 static svn_error_t *
> 186 test_error_symbolic_name(apr_pool_t *pool)
> 187 {
> 188 struct {
> 189 svn_errno_t errcode;
> 190 const char *errname;
> 191 } errors[] = {
> ⋮
> 208 #ifdef SVN_DEBUG
> 209 { ENOENT, "ENOENT" },
> 210 { APR_ENOPOOL, "APR_ENOPOOL" },
> 211 #endif
> ⋮
> 219 };
> ⋮
> 222 for (i = 0; i < sizeof(errors) / sizeof(errors[0]); i++)
> 223
> SVN_TEST_STRING_ASSERT(svn_error_symbolic_name(errors[i].errcode),
> 224 errors[i].errname);
>
> svn_error_symbolic_name()'s support for OS error codes, such as ENOENT, is
> implemented in build/generator/gen_base.py:
>
> 264 def write_errno_table(self):
> 265 # ### We generate errorcode.inc at autogen.sh time (here!).
> 266 # ###
> 267 # ### Currently it's only used by maintainer-mode builds.
> If this
> 268 # ### functionality ever moves to release builds, it will
> have to move
> 269 # ### to configure-time (but remember that Python cannot be
> assumed to
> 270 # ### be available from 'configure').
> 271 import errno
> ⋮
> 299 # errno names can vary depending on the Python, and
> possibly the
> 300 # OS, version and they are not even used by normal release
> builds
> 301 # so omit them from the tarball. We always want the struct
> itself
> 302 # so that SVN_DEBUG builds still compile and it needs a
> dummy
> 303 # entry to avoid a zero-sized array.
> 304 write_struct('svn__errno',
> 305 [(0, "success")] if self.release_mode
> 306 else errno.errorcode.items())
>
> «self.release_mode» is true when gen-make.py is run by «autogen.sh --release»,
> which is how autogen.sh is run by the tarball rolling scripts.
>
> Consequently, the ENOENT test case fails when building a tarball with
> --enable-maintainer-mode.
>
> I'm not sure how to fix it.
>
> Could we just guard the ENOENT test case with «#if SVN_VER_REVISION == 0»?
> That would be mostly correct, though the guard wouldn't be necessary when
> building tags from a working copy (rather than tarball) in maintainer mode.
We could add code to those scripts so that 'autogen.sh --release' would
cause '#define SVN_RELEASE_MODE 1' to be added to svn_private_config.h,
then the test could take that into account.
-- Brane
