[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/errorcode.inc and
> subversion/libsvn_subr/config_keys.inc 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.
errorcode.inc 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 errorcode.inc
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 errorcode.inc
when one of its two sources changed is worth the code churn.
In release tarballs, the errno stringification map (int->string) in
errorcode.inc includes the values from the system dist.sh ran on.
Therefore, a user who does a maintainer-mode build off a tarball without
running autogen.sh 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 gen-make.py to avoid generating the errorcode.inc errno
stringification map when rolling a tarball?
As to config_keys.inc, 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 Makefile.in doesn't
help Windows devs.)
In short, I agree that we should make touching svn_config.h regenerate
config_keys.inc, but I'm not sure how to implement this.
Cheers,
Daniel
¹ Makefile.in, dist.sh, two vcproj templates, and gen-make.py.
P.S. The worst case for changing svn_config.h without regenerating
config_keys.inc 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
context.
> The fix would be to write a Makefile.in rule that regenerates (just) the
> .inc file when the respective .h file changes. The files arae
> regenerated by these lines in gen-make.py:
> 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).
>
> config_keys.inc is new from today, errorcode.inc 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
>
Received on 2015-05-10 18:15:42 CEST