On Wed, Sep 4, 2019 at 4:14 PM Varun Iyer <varun_iyer@posteo.net> wrote:
>
> On 19/09/04 03:42PM, jim.cromie@gmail.com wrote:
> > in the kernel, there are a lot of usages of __FILE__
> >
> > this means that there are a lot of copies of fully rooted paths,
> > including all the varying ~/src/linux prefixes used by individual builders.
>
> On gcc, `__FILE__` is the path of the file relative to the directory that the
> build is run from.
>
> Try something like
>
> #include <stdio.h>
> #define testing() printf("%s\n", __FILE__)
> int main() { testing(); }
>
> and compile it from different directories to replicate this behaviour.
>

whoa.  how long have I been out ?

per https://www.cprogramming.com/reference/preprocessor/__FILE__.html
__FILE__ is a preprocessor macro that expands to full path to the current file.

and thanks for that simple demo.
I shoulda done that myself, but I had no concept that such a change
might happen.

and its not the whole story.
when I rebuild from .. the __FILE__ value changes

[jimc@frodo play]$ make gcc/file.o
cc    -c -o gcc/file.o gcc/file.c
[jimc@frodo play]$ make gcc/file
cc   gcc/file.o   -o gcc/file
[jimc@frodo play]$ gcc/file
gcc/file.c

so its build-path relative (which u pretty much said), but I doubt its
that simple either.
I presume it is also controllable / customizable using one or more
make variables or techniques.
linux/Makefile's  $srctree variable looks to be involved
Perhaps this is (one more reason) why (shell-descent) recursive makes
are less than desirable ?

In any case I added a printk("__FILE__: %s\n", __FILE__)
to see for myself, and you are correct.

So I feel compelled to offer a fix for dynamic_debug, attached.
hopefully it explains adequately, I have some doubts..

maybe this should go to LKML now,
but I guess Id prefer to make my obvious thinkos less publicly.
Im happy to bikeshed the commit-msg or code.