[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()

[infinity0 at pwned dot gg]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268

--- Comment #14 from infinity0 at pwned dot gg ---
> it has a unified option (-ffile-prefix-map) [..]

Oh, nice. That might save me some work, then.

Could you bounce me the thread? Or failing that, tell me the Message-ID of one
of the messages, so I can reply to it.

> [..] that I believe does exactly what you want

Basically yes. However one minor extra thing my patch enables, is the remapping
of arbitrary file paths - whereas the current form can't remap paths with "="
in it. This is not a major issue, but I'd recommend that you change:

-  p = strchr (arg, '=');
+  p = strrchr (arg, '=');

This would be a bit more flexible.

> the environment variable is a bad idea.

The problem with doing this on the command-line is that the command-line
arguments then contain the build-path. Sometimes, builds like to save the
command-line arguments somewhere.

Using an environment variable avoids this issue. I agree envvars are dirty in
general, but in this case one would be *removing* information from what GCC is
already doing (taking in absolute-path information via the filesystem), as
opposed to *adding* information which is what other envvars do.

A more refined way to avoid this issue, is to allow $-based substitution, like
`-ffile-prefix-map=$BUILD_PATH=/usr/my/path` where BUILD_PATH is read from the
environment. Then we avoid adding $BUILD_PATH to the command-line args, but
/usr/my/path is still in there. Daniel Kahn Gillmor implemented this here [1]
though it was rejected in favour of a simpler approach for the bug mentioned
#69821 [2], however in retrospect this mechanism is actually very useful and
flexible. I found out recently that NetBSD still carries this patch to this
day, for reproducible builds. [3]

[1] https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01168.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69821
[3]
http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/final.c?rev=1.2&content-type=text/x-cvsweb-markup