HW42:
>> 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
SRCROOTDIR or SOURCEROOTDIR anyways.
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
name.
If nobody else has any comments, I'm going to proceed next week with this name,
with
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.)
X
[1] https://codesearch.debian.net/search?q=\bSOURCE_ROOT_DIR\b
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
