Delphi ignores path to unit in .dpr

[Vandrovnik 214]

Hello,

 

from Delphi 10.3.3, I have in .dpr, among other used units, this line:

  IBX.IBStoredProc in 'C:\Program Files (x86)\Embarcadero\Studio\20.0\source\IBX\IBX.IBStoredProc.pas',

(there was a bug in IBX, so I changed the source and added it to project, so that it was compiled with it).

 

Now with Delphi 10.4.2, the file does not exist on that path. But when I build the project, there is no error, no warning, no hint... It silently uses already compiled IBX.IBStoredProc in the same way, as it would, if I did not put full path in .dpr file. Is that expected and correct, or should be reported?

 

[Stefan Glienke 2002]

Unfortunately as far as I remember this has been an issue since ages and I once in a while step into that trap myself and shrug it off with "well, whatever".

I am very sure it had been reported before but cannot find anything in JIRA right now - maybe it was in the old system - feel free to report it.

[Guest]

38 minutes ago, Vandrovnik said:

It silently uses already compiled IBX.IBStoredProc in the same way, as it would, if I did not put full path in .dpr file. Is that expected and correct, or should be reported?

I think that the Compiler/IDE only search a new DCU if old dont exist, then, if any dcu (with name used in your project) is founded, and, none error with him, any other try would be discarted.

Or be, if the DCU found in PATH ( see the hierarchy of searches...) then, it would be used.

 

Now, this it's stored on .DPROJ files in fact, not really in .DPR file. For test this, try delete your DPROJ file and your project will use the global PATH by IDE definitions or any Compiler options/config file.

• I think that the file-path on .DPR file is for easy Project Manager use, you see me?
• in .DPROJ file you can overwrite any global definions 

 

hug

[Vandrovnik 214]

In .dproj file, there is also full path to non-existent file:

<DCCReference Include="C:\Program Files (x86)\Embarcadero\Studio\20.0\source\IBX\IBX.IBStoredProc.pas"/>

[Attila Kovacs 629]

@Vandrovnik there is the global library path, then there is a search path in the project options, and there is the project root dir where the IDE looks for the files. In reversed order as I wrote them.

 

So either copy it to your project root or into a separate dir and add it to the project search path.

Edited March 24, 2021 by Attila Kovacs

[Stefan Glienke 2002]

The order the compiler uses to find units is not the issue - the issue is that the compiler silently ignores the explicitly stated path to the source file in the uses clause of the dpr.

 

And even if it has been the case since the dawn of time - does anyone really think that is a feature worth to have "I know you told me the file has to be at this exact location. But it was not so I just ignore it and look somewhere else, k?"

Applying the principle of least astonishment to how the compiler deals with this situation would be to raise an error and tell the user that the file was not found where it was supposed to be.

I am very sure this is more helpful than simply ignoring this information and look somewhere else to produce a successful compilation.

 

In fact I even believe this is one of the many cases that lead to those dreaded dcu outdated errors because when you compile a pas the produced dcu is being put into the unit output directory.

If you now move around your pas file but miss to change the path in the dpr/dpk because you don't do it in the IDE you might still succeed compiling because now the compiler uses the dcu from the output directory until things go out of sync and the dcu is outdated.

Edit: I just tested this and unless the output dir is explicitly listed as search path this situation does not happen *unless* the unit is still open in the IDE regardless its existence in the file system.

Edited March 24, 2021 by Stefan Glienke

[Attila Kovacs 629]

yeah we know that, is that new?

try to make it relative to the project root, but I would explicitly define it in the search path from a dedicated directory like myrtlpatches/xyz

 

the order is project root, library path, search path, so either comes into the project dir or with relative path into the dpr.

 

 

Edited March 24, 2021 by Attila Kovacs

[Guest]

the only chance is "delete the dcu existent" forcing a new compilation if "source file" is found!!!

 

hug

[Guest]

I have done a test with a unit (form) save in "..\myproject\21\uFormSecond.pas"

then, I have compiled. ok.

later, i have changed (manually) in DPR file to "..\myproject\212\uFormSecond.pas"

resulted: my compilation dont works... then, I have the revert old changes or rename my subfolder to "212"

same that my "dcu compiled" is founded on ..\Win32\Debug folder.

 

summary: the IDE/compiler can not be watching the "manual" changes !!!

hug

Edited March 24, 2021 by Guest

[Attila Kovacs 629]

44 minutes ago, Stefan Glienke said:

But it was not so I just ignore it and look somewhere else, k?

Well I'm not sure on that.

 

Edit, so I've tested it:

 

If the unit in the dpr is not found the compiler looks for the dcu's in this order:

project root

library path

search path

(but not in the "dcu out" path)

 

explicit and relative paths are also working for the dpr (Berlin U2)

 

if a unit is opened in the IDE and the path in the dpr matches, you can rename/remove the unit, the project will still compile.

 

 

Edited March 24, 2021 by Attila Kovacs

[Vandrovnik 214]

In my case, IBX.IBStoredProc is not "my" unit, it comes with Delphi (IBX package). I have appended it to the project in Delphi 10.3.3 just to make Delphi to compile it with a patch. Now I was surprised that project builds fine, even when the file does not exist anymore. Delphi probably finds C:\Program Files (x86)\Embarcadero\Studio\21.0\lib\win32\release\IBX.IBStoredProc.dcu and silently uses it, but I do not believe this is correct. I think this can be good source of hard to find bugs, while an error or at least a warning would help to prevent them.

 

I have reported it here: https://quality.embarcadero.com/browse/RSP-33506