Hey everyone,

I've already asked this on the PR that added __FILE_FULL_PATH__ (see https://github.com/dlang/dmd/pull/5959#issuecomment-2423255282) but there is no reply probably because that PR is long merged.

So, I'd like to repeat my question here: Is that intentional that the returned path is not normalized?

Our code base tends to use __FILE_FULL_PATH__ as a template argument, now I'm trying to split the compilation and let's say I compile lib/*.d separately and then compile bin/*.d passing -I../lib flag to find imports. The resulting object files can't be linked, because template arguments are project_dir/lib/module.d in one object file but project_dir/bin/../lib/module.d in another.

Of course, this could be solved by changing the build to never use .. (or .) in the paths passed to the compiler (or use them consistently everywhere)... Or by replacing __FILE_FULL_PATH__ with __FILE_FULL_PATH__.buildNormalizedPath everywhere (well, doesn't even have to be everywhere, just everything that might end up in templates' arguments).

But I wonder, shouldn't __FILE_FULL_PATH__ be normalized in the first place?

Try __MODULE__?

On Thursday, 24 October 2024 at 18:25:21 UTC, Kagamin wrote:

Hm. Thanks a lot for your suggestion, but that doesn't answer my question.

The question is: are there reasons not to normalize __FILE_FULL_PATH__? Are there use cases where it matters? And if not, should the compiler normalize the path internally? I'm happy to send the PR, but wanted to make sure I'm not missing anything first.