subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject Re: Build system bug affecting svn_error_codes.h and svn_config.h only
Date Sun, 10 May 2015 16:15:24 GMT
[question to build.conf experts inside; grep for "newer"]

Daniel Shahaf wrote on Fri, Apr 17, 2015 at 16:26:48 +0000:
> Philip points out that subversion/libsvn_subr/ and
> subversion/libsvn_subr/ are not regenerated when
> svn_error_codes.h and svn_config.h (respectively) change.

That's not quite accurate.  svn_error_codes.h is not used in the
generation of these two files. is generated from tools/dev/aprerr.txt (a static file) and
data from Python's 'errno' module.  The data from these two sources is
only used to have svn_error_symbolic_name() stringify APR and OS error
codes in maintainer-mode builds.  Failing to regenerate
when aprerr.txt is touched or Python is upgraded only means
svn_error_symbolic_name() will fail to stringify some error codes
— which could happen anyway if the APR shared library were upgraded
without rebuilding Subversion against an updated aprerr.txt.  And,
again, all this only applies to maintainer-mode builds.  So I don't
think adding buildsystem glue to automatically rebuild
when one of its two sources changed is worth the code churn.

In release tarballs, the errno stringification map (int->string) in includes the values from the system ran on.
Therefore, a user who does a maintainer-mode build off a tarball without
running first, on an OS that uses different errno numbers
than the release manager's OS, would see svn_error_symbolic_name() would
return wrong results when called on errno values (either directly or
because an APR call returned errno as its apr_status_t return value).
Should we teach to avoid generating the errno
stringification map when rolling a tarball?

As to, it's indeed generated from svn_config.h.  I'm not
sure how to implement automatic regeneration of the former whenever the
latter is touched.  By comparison, the .sql->.h conversion seems to be
hard-coded in five different places¹.  Is there a way to easily tell
build.conf "Whenever file X is newer than file Y, run command Z"?  
(In a way that works on all platforms; editing doesn't
help Windows devs.)

In short, I agree that we should make touching svn_config.h regenerate, but I'm not sure how to implement this.



¹,, two vcproj templates, and

P.S. The worst case for changing svn_config.h without regenerating is that 'svn --config-option=foo:bar:baz=' will warn
about the newly-added values in the triplet.  The svn operation will
continue normally and the triplet will be properly set in the client

> The fix would be to write a rule that regenerates (just) the
> .inc file when the respective .h file changes.  The files arae
> regenerated by these lines in
>   generator.write_errno_table()
>   generator.write_config_keys()
> I note that the line before those two is write_sqlite_headers(), which
> already works correctly (touching .sql regenerates its .h).
> is new from today, has around since
> early in the 1.9 release cycle.
> I'm not sure what's the situation in the windows build with respect to
> this issue.
> Daniel

View raw message