If we build dbus twice with the same platform and toolchain (in particular the same version of the same compiler), it should be possible to get binary-identical results. See <https://reproducible-builds.org/> for more information on reproducible builds. Because we use __FILE__ in debug messages, we can't have reproducible builds unless we invoke configure with a relative path (like the Debian packages of dbus do), but that's easy for a distributor to do if they consider reproducible builds to be important. (That means this should be reproducible, and not hard-code /tmp/dbus/src or /tmp/dbus/builds/optimized into binaries: cd /tmp/dbus git clone ... src mkdir -p builds/optimized cd builds/optimized && ../../src/configure ... but it's OK if this isn't: cd /tmp/dbus git clone ... src mkdir builds/optimized cd builds/optimized && /tmp/dbus/src/configure ... )
Created attachment 130858 [details] [review] Pass in DBUS_TEST_EXEC via environment, not hard-coded into binaries This avoids "capturing" the build directory in the built binaries when built with embedded tests, which is good for reproducible builds. See <https://reproducible-builds.org/> for more information.
Created attachment 130859 [details] [review] Doxyfile.in: do not put timestamps in HTML The build timestamp is not particularly useful (the version number of the package is already present in the HTML), and it prevents the build from being reproducible. See <https://reproducible-builds.org/> for more information.
Comment on attachment 130858 [details] [review] Pass in DBUS_TEST_EXEC via environment, not hard-coded into binaries Review of attachment 130858 [details] [review]: ----------------------------------------------------------------- Shouldn’t DBUS_TEST_EXEC also be set in the environment in cmake/modules/Macros.cmake?
Comment on attachment 130859 [details] [review] Doxyfile.in: do not put timestamps in HTML Review of attachment 130859 [details] [review]: ----------------------------------------------------------------- ++
Comment on attachment 130859 [details] [review] Doxyfile.in: do not put timestamps in HTML Applied, thanks
(In reply to Philip Withnall from comment #3) > Shouldn’t DBUS_TEST_EXEC also be set in the environment in > cmake/modules/Macros.cmake? Yes, good catch. I'd forgotten we ran these tests in cmake-land.
With the patch I'm about to attach: $ ctest -V ... test 1 Start 1: test-dbus 1: Test command: /home/smcv/tmp/build/dbus/cmake/bin/test-dbus "--tap" 1: Environment variables: 1: DBUS_TEST_DAEMON=/home/smcv/tmp/build/dbus/cmake/bin/dbus-daemon 1: DBUS_SESSION_BUS_ADDRESS= 1: DBUS_FATAL_WARNINGS=1 1: DBUS_TEST_DATA=/home/smcv/tmp/build/dbus/cmake/test/data 1: DBUS_TEST_DBUS_LAUNCH=/home/smcv/tmp/build/dbus/cmake/bin/dbus-launch 1: DBUS_TEST_EXEC=/home/smcv/tmp/build/dbus/cmake/bin 1: DBUS_TEST_HOMEDIR=/home/smcv/tmp/build/dbus/cmake/dbus which is indeed where the binaries end up.
Created attachment 130897 [details] [review] Pass in DBUS_TEST_EXEC via environment, not hard-coded into binaries --- Now setting the environment variable for cmake as well. ${PREFIX} is either empty (under normal circumstances) or "z:" (when we are testing a mingw build on Windows using Wine, and so we want z:/home/whatever, making use of Wine's default "mount" of Unix "/" on fake Windows "Z:\")
(In reply to Simon McVittie from comment #8) > ${PREFIX} is either empty (under normal circumstances) or "z:" (when we are > testing a mingw build on Windows using Wine Er, that should say testing a mingw (Windows) build on *Linux* using Wine.
Comment on attachment 130897 [details] [review] Pass in DBUS_TEST_EXEC via environment, not hard-coded into binaries Review of attachment 130897 [details] [review]: ----------------------------------------------------------------- ++
Fixed in git for 1.11.14, thanks for reviewing!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.