error-test.c false positive when building tarballs in maintainer mode

[Daniel Shahaf <d....@daniel.shahaf.name>]

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.

Cheers,

Daniel

Re: error-test.c false positive when building tarballs in maintainer mode

[Branko Čibej <br...@apache.org>]

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