>> I preferred the ${x}dir style instead of dir_${x} or ${x}_dir because
>> of some existing conventions like
>> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> Well, OTOH, freedesktop.org uses _DIR:
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Good point, and "properly" following the GNU convention I mentioned would be 

I'm going to suggest SOURCE_ROOT_DIR - I think it sounds more natural and 
consistent than SOURCE_DIR_ROOT, the concept is more like (source code's (root 
(directory)) and not, e.g. (a (source directory)'s root), and in English we 
don't usually put adjectives after the noun.

The name is only used by 2 packages [1] and these cases are both source-code 
constants and not environment variables. So I think it's for us to take the 

If nobody else has any comments, I'm going to proceed next week with this name, 

1. writing some text/arguments to promote this to gcc

2. amend dkg's patch to do what we just discussed. (also -ffile-prefix-map, 
also fix __TIMESTAMP__ to use SOURCE_DATE_EPOCH whilst I'm at it)

3. think about the semantics of a spec. In particular, and unlike 
SOURCE_DATE_EPOCH, I think it's OK for upstream projects to override this 
themselves. For example, sometimes project A likes to put external project B in 
a subdirectory b/, but we still want to debug as if b/ was the root. (In Debian 
we try very hard to just `rm -rf b/` but there *are* important cases where we 
make an exception to this.)


[1] https://codesearch.debian.net/search?q=\bSOURCE_ROOT_DIR\b

GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Reproducible-builds mailing list

Reply via email to