[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 >
