make: introduce __SHORT_FILE__ define

[kaspar030]

While fiddling with the logging, I realized that currently the RIOT make system uses absolute paths for filenames, causing __FILE__ to contain the full path.

That is longer than necessary and also exposes the build system (the messages contain e.g., "/home/kaspar/src/riot.bullshit/*"...), it makes it a lot harder to get reproducable builds built on different build systems.

So I propose the define __SHORT_FILE__ that only contains the path starting from $(RIOTBASE).
I tried redefining __FILE__, but gcc complains about that.

Opinions?

[OlegHahm]

The idea sounds good, but the patch some doesn't work for me. It's still showing the full path.

[kaspar030]

Well, did you use __SHORT_FILE__ instead of __FILE__? Can you check whether building with QUIET=0 shows the correct define?

I'm replacing $(RIOTBASE)/, maybe this breaks if $(RIOTBASE) already contains a trailing "/"?

[OlegHahm]

Nevermind, I misinterpreted the purpose of this PR. I thought it should affect the output of the Make system itself.

[jnohlgard]

I think that a more robust way would be to do $(patsubst $(RIOTBASE)/%,,$(abspath $<))

[jnohlgard]

I like this, I didn't like the output from the debug messages with filenames because of the length.

[kaspar030]

@gebart changed to patsubst. Why do you think it's more robust?

[cgundogan]

I also like this idea. What about additionally introducing something like __FILE_NAME__ which only extracts the non-directory part? So e.g. /home/cnk/RIOT/examples/rpl_udp/udp.c => udp.c?
Could be done easily with the $(notdir names…) function [1].

Opinions?

[1] https://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html

[jnohlgard]

@kaspar030

changed to patsubst. Why do you think it's more robust?

Because with patsubst you can make sure that you are only replacing the prefix of the filename, in case RIOTBASE is set to something really short, and that exists in the tree, like /sys/net (though I admit that example is quite stupid).

I'm replacing $(RIOTBASE)/, maybe this breaks if $(RIOTBASE) already contains a trailing "/"?

You don't have to worry about that since when you run abspath on the filename any multiple slashes will be replaced by single slashes and any /./ and /../ will be followed and eliminated from the path.

[cgundogan]

How should symlinks be handled? abspath e.g. does not resolve symlinks, while realpath does. A matter of taste probably.

[jnohlgard]

@cgundogan

How should symlinks be handled? abspath e.g. does not resolve symlinks, while realpath does. A matter of taste probably.

I would argue that if you have set RIOTBASE to a symlink, then you probably want to use the symlink to refer to that path and not the real path name.

[cgundogan]

@gebart completely valid and I agree with you. I was just giving food for thought (:

[kaspar030]

Is it me or did they disable the button to re-start a failed travis job?

[OlegHahm]

It's still there. Are you logged in?

[kaspar030]

Ah, no, I wasn't. Thx.

[kaspar030]

I don't quite like that "short file" and "file name" don't really show what's the exact difference. "short file" alone made sense together with "file", but like this... Do you have ideas for better names?

[cgundogan]

What about __RELATIVE_FILE__ and __SHORT_FILE__. With the latter being
the former __FILE_NAME_?
Am 12.05.2015 15:48 schrieb "Kaspar Schleiser" [email protected]:

I don't quite like that "short file" and "file name" don't really show
what's the exact difference. "short file" alone made sense together with
"file", but like this... Do you have ideas for better names?

—
Reply to this email directly or view it on GitHub
#2969 (comment).

[jnohlgard]

@cgundogan How about the other way around, use FILE as a prefix:

__FILE_RELATIVE__
__FILE_NAME__

or, instead of __FILE_NAME__:
__FILE_BASENAME__ (to associate with basename in the shell)
or __FILE_NOPATH__

[kaspar030]

I like __FILE_RELATIVE__ and __FILE_NOPATH__ best so far.

[cgundogan]

+1 to FILE_RELATIVE and FILE_NOPATH
Am 13.05.2015 10:50 schrieb "Kaspar Schleiser" [email protected]:

I like FILE_RELATIVE and FILE_NOPATH best so far.

—
Reply to this email directly or view it on GitHub
#2969 (comment).

[Kijewski]

I strongly vote against introducing new double underscores now that we eliminated them from the header file guards ...

[jnohlgard]

@Kijewski you're right.
Is it too long to have RIOT_FILE_NOPATH and RIOT_FILE_RELATIVE?

[Kijewski]

@gebart, I think RIOT_FILE_NOPATH and RIOT_FILE_RELATIVE are readable and self-explanatory. 👍

[kaspar030]

Someone dares to say ACK and merge?

[jnohlgard]

Untested ACK (from my phone, can't run it)

[jnohlgard]

Go if Travis is green