Oh cool, thanks a lot for the pointer! I had assumed the upstream Debian packaging effort was using conventional bloom/GBP workflow— didn’t realise it was its own thing. Nice work.
My scenario is similarly building via a dsc, but not using the standard toolchain at all; I build a big chunk of packages all at once, in parallel, using catkin_tools. See for an example the rules file from this demonstration repo: https://github.com/mikepurvis/ros-bundling/blob/master/debian/rules
So anyway yes, looking at your log for ros-ros-comm, an individual line is like:
cd /«PKGBUILDDIR»/build/clients/roscpp && /usr/bin/c++ -DROSCONSOLE_BACKEND_LOG4CXX -DROS_PACKAGE_NAME=\"roscpp\" -Droscpp_EXPORTS -I/«PKGBUILDDIR»/build/devel/include -I/«PKGBUILDDIR»/clients/roscpp/include -I/«PKGBUILDDIR»/build/devel/include/ros -I/«PKGBUILDDIR»/tools/rosconsole/include -I/«PKGBUILDDIR»/utilities/xmlrpcpp/include -I/«PKGBUILDDIR»/build/clients/roscpp -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -std=c++11 -Wall -Wextra -o CMakeFiles/roscpp.dir/src/libros/poll_set.cpp.o -c /«PKGBUILDDIR»/clients/roscpp/src/libros/poll_set.cpp
I’ve already normalized my buildpath, so debug-prefix-map shouldn’t matter. Nothing else here stands out to me as being the thing, unless it’s PIC/PIE that does it. Do you happen to know? The other thing working against me I suppose is that all this is on Trusty, with GCC 4.8.2. Perhaps some stuff has changed in GCC 5/6 that makes reproducibility the default? I can make my build pull in a newer compiler if I have to, but I’d prefer not to bother unless that’s likely to be the issue.