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


Reply via email to