Currently `dmd @cmdfile` will read file as simple char string. But when DUB is compiling and creating this file it always saves it in UTF-8.
This makes a problem when cmdfile contains paths (source files) with non-ASCII paths/names and thus DMD interprets them incorrectly (it always uses WinAPI ANSI functions which expects them to be encoded in Windows default ANSI code page)
Such cmdfile file with non-ASCII paths encoded as UTF-8 will produce "Error: cannot read file"
One solution could be to change DUB to save it in Windows default ANSI code page, but I think that's a very bad idea because then that file won't be portable.
So best would be to enforce it being in UTF-8 encoding and then decode in DMD for respective code page which is used for WinAPI calls.
(In reply to Dāvis from comment #0)
> One solution could be to change DUB to save it in Windows default ANSI code
> page, but I think that's a very bad idea because then that file won't be
> portable.
It doesn't need to be portable, it's just used for a single compiler invocation.
> So best would be to enforce it being in UTF-8 encoding and then decode in
> DMD for respective code page which is used for WinAPI calls.
UTF-8 sounds reasonable.