On Friday, 22 July 2016 at 08:36:37 UTC, Jonathan Marler wrote:
On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote:
On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote:
On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote:
What's wrong with __FILE__.dirName ?
It's kinda weird, sometimes I've noticed that the __FILE__
keyword is an absolute path, and sometimes it isn't. If it
was always an absolute path, that would work. I decided to
take a stab at implementing this in the dmd compiler:
https://github.com/dlang/dmd/pull/5959
It adds a __FILE_FULL_PATH__ trait which would solve the
issue.
Personally I've never seen a relative __FILE__. Is this an
issue that's confirmed ?
I mean that it would be better to fix __FILE__ so that its
result is always absolute then. I think that such a "PPR"
(punk-pull-request) has 0% chance of being accepted,
especially since it adds a special keyword !
It's definitely confirmed. And now that I've walked through
the source code, I see that it wasn't implemented to be an
absolute path, it just happens to be some of the time depending
on how the file is found. I'm sure Walter will have an opinion
as to what solution he prefers. Either redefining the __FILE__
trait or adding a new one. He's communicating fixes to the PR
on github so that a good sign. We'll see.
Yes, i've seen he 's started to review.
I don't know if you've seen my other suggestion but another
solution would be to force relative fnames passed to the compiler
to be translated to absolute. This is also why I've never seen a
relative __FILE__. The build tool I use always does the expansion
in intern before calling the compiler.
