doc: remove documentation on deprecated RIOT_FILE_* macros

[mguetschow]

Contribution description

#21170 added documentation about RIOT_FILE_RELATIVE and RIOT_FILE_NOPATH which were already considered obsolete in #18936. Instead of going through the deprecation hoops I'd propose to just revert these commits before the next release.

Issues/PRs references

Reverts #21170.

[riot-ci]

Murdock results

✔️ PASSED

bffa112 doxygen: remove deprecated RIOT_FILE_RELATIVE

Success	Failures	Total	Runtime
1	0	1	01m:28s

Artifacts

• Documentation preview

[crasbe]

That change is good, because with the current CFLAGS in makefiles/cflags.inc.mk, the documentation is incorrect:
@see __FILE__ for absolute filenames that also work with *.h files

vs.

RIOT/makefiles/cflags.inc.mk

Lines 98 to 99 in 04a1698

	# Don't include absolute path in __FILE__ macro
	OPTIONAL_CFLAGS += -fmacro-prefix-map=$(RIOTBASE)/=

[crasbe]

Small nitpick: There is an excess whitespace in one of your commits in front of the "doc".

[crasbe]

From my side, this is good to go, but I'd prefer to leave the decision to @miri64.

You can probably prepare a PR already to remove RIOT_FILE_* entirely, but merging has to wait until #21110 is merged (if you don't want to force @Ollrogge to rebase 😅 ).

[Ollrogge]

From my side, this is good to go, but I'd prefer to leave the decision to @miri64.

You can probably prepare a PR already to remove RIOT_FILE_* entirely, but merging has to wait until #21110 is merged (if you don't want to force @Ollrogge to rebase 😅 ).

all good, I dont mind rebasing :)

[miri64]

If we can use standard macros without spilling the absolute path 👍 from my side.

[miri64]

But wait... should we maybe go through the official deprecation cycle first. So deprecate them for removal after the 2025.10 release?

#21320 (comment)

[mguetschow]

But wait... should we maybe go through the official deprecation cycle first. So deprecate them for removal after the 2025.10 release?

Well, since they've never been documented (and not used throughout the codebase in the last years), I'd argue this is not part of the public API and therefore doesn't qualify for the deprecation process. In particular, the documentation from #21170 hasn't made it into any release yet.

[miri64]

Well, since they've never been documented (and not used throughout the codebase in the last years), I'd argue this is not part of the public API and therefore doesn't qualify for the deprecation process.

Only because something is not documented, doesn't mean it is not used. It was a feature that has been there for years and though hidden, people might still rely on it. Is there any hurry to get it out? If no, let's go the official path. If yes, the reasons should be clearly stated in OP.

In particular, the documentation from #21170 hasn't made it into any release yet.

Our documentation is not tagged to releases, so I find this sentence a somewhat strange claim.

[mguetschow]

Is there any hurry to get it out? If no, let's go the official path

Alright, closing in favor of #21345