Sune Stolborg Vuorela wrote: > Can you provide some kind of hook in the environment so we at least can work > around it in the users, so that the internal functions (where the output of > __FILE__ is forwarded to) can glue e.g. the content of an environment > variable in front of the usage of the __FILE__ content to try to > reconstruct it at runtime, so that all packages doesn't need to do export > SOURCE_BASE_DIR=`pwd`; make test, but it will just work if we patch Qt and > similar libraries ?
+1 for the request for the build system to provide for a reference point for where the source is to be found. SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the algorithm for use is similar: if it is in the environment then use it, if not, fall back to the previous behaviour. At its crudest level, a package's debian/rules could include SOURCE_BASE_DIR= $(shell pwd); however, putting this into the build environment saves source changes in multiple packages, sets us up for future use across the entire ecosystem, signals to upstreams that this is a broad standard and not a mere hack in d/rules, and also saves maintainers from thinking about nasty corner cases to do with current directories with makefile invocation. Looking to the future, tests using SOURCE_BASE_DIR to locate test data would allow build-time tests to be repurposed as autopkgtest tests too, as the autopkgtest could tell the tests where the test input data is to be found. This would be a substantial improvement on the current situation where the tests can only be run at build time and not on ci.debian.net. By dpkg making SOURCE_BASE_DIR 'real', there is a distinct prospect of Debian carrying Qt5 patches to use it (thanks Sune!) and for Qt6 to include them upstream. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
