I was getting quite obscure linker errors in a project. I reduced it to this: __FILE__ generates sometimes relative paths even though all files and '-I' paths are given as absolute paths, depending on the directory in which 'dmd' is launched. ---------------------------- /mydir/fun1.d: import fun2; void test(){ test2(); } /mydir/fun2.d: void test2(string file=__FILE__)(){ if(false) test2(); } ----------------- cd /mydir/ dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d && nm /tmp/fun1.o |ddemangle |grep test2 S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2() S pure nothrow @nogc @safe void fun2.test2!("fun2.d").test2() ----------------- cd / #or anywhere else dmd -of/tmp/fun1.o -c -I/mydir/ /mydir/fun1.d && nm /tmp/fun1.o |ddemangle |grep test2 S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2() S pure nothrow @nogc @safe void fun2.test2!("/mydir/fun1.d").test2() The difference is: 'test2!("/mydir/fun1.d")' vs 'test2!("fun2.d")' I believe 'test2!("fun2.d")' is wrong. Maybe related: http://www.digitalmars.com/d/archives/digitalmars/D/learn/exclude_current_directory_from_search_path_in_dmd_69919.html "exclude current directory from search path in dmd ?" (which i asked on the forum but didn't get answer to)
Using __FILE__ as template parameter is definitely bug-prone. Related forum discussion: https://forum.dlang.org/thread/induraqegvpyomvzxwmf@forum.dlang.org
there's __FILE_FULL_PATH__ now
I still think this is a bug and related bugginess of __FILE__ as mentioned in the forum post. Yes there is __FILE_FULL_PATH__ but that does not help with libraries distributed in binary+.di (include files). See the forum post above for details.