Bug in -J

[Mr. Pib via Digitalmars-d]

On Saturday, 12 August 2017 at 03:02:31 UTC, Vladimir Panteleev 
wrote:
> On Saturday, 12 August 2017 at 02:45:30 UTC, rikki cattermole 
> wrote:
>> On 12/08/2017 3:34 AM, Mr. Pib wrote:
>>> I have -J added to the command line like
>>> 
>>> -JC:\Temp
>>> 
>>> I then use import(r"C:\Temp\a.dat");
>>> 
>>> and I get an error about the file not existing in the
>>> 
>>> main.d: Error: file "C:\\Temp\\a.dat" cannot be found or not 
>>> in a path specified with -J
>>> 
>>> It seems dmd does internally compare the paths to see if they 
>>> are identical.
>
> No, it just prefixes the given import() path will all those 
> given by -J.
>
>>> Of course, removing the C:\Temp\ part of import works fine.
>>> 
>>> The problem with that approach is it then is not consistent 
>>> with other code. I need to specify the full path because 
>>> sometimes it is used.
>>> 
>>> essentially
>>> 
>>> version(X)
>>> import(path)
>>> else
>>> load(path);
>
> I don't understand why you would want to do that. Using 
> absolute paths makes assumptions about the system your software 
> is being built on. Even if you never plan to build the software 
> on any computer but your own, it still seems like a 
> questionable design decision.
>

You are making assumptions about me making assumptions... please 
don't make any more assumptions or we will be in an infinite 
regression ;/

>>> while I could do something like
>>> 
>>> import(baseName(path))
>>> 
>>> it seems kinda clunky, in any case. It's pretty obvious that 
>>> one excepts the same behavior so it could create bugs in code 
>>> that except the behavior to work correctly.
>
> You could also use -J/ and import(path[1..$]) (or the Windows 
> equivalent). Still a bad idea.
>
>> Most likely related or is the issue[0].
>>
>> [0] https://issues.dlang.org/show_bug.cgi?id=3420
>
> Nope.

If are aware, it has nothing to do with absolute paths as the bug 
should also be exhibited with relative paths. It is a comparison 
issue of the strings rather than checking to see if they 
represent the same physical location.

It would be like saying that \x\y is different from \x\..\x\y. 
Dmd does a blind comparison, I bet, rather than what it should be 
doing. Obviously \x\y are different strings but they are not 
different file locations.

If that is not the case, then a better error message should be 
given.