$UNITPATH directive misinterprets relative paths
Original Reporter info from Mantis: bunnylin @bunnylin
-
Reporter name: Kirinn
Original Reporter info from Mantis: bunnylin @bunnylin
- Reporter name: Kirinn
Description:
The $UNITPATH compiler directive is supposed to be equivalent to the commandline switch -Fu, but on 3.2.0 RC1 it seems the directive is always implicitly prefixed with a slash, causing an incorrect unit path to be added. That is, "unitdir" is treated as "/unitdir". Using "-Fuunitdir" on the commandline still works as expected.
In the below test case, attempting to use both {UNITPATH unitdir} and {
UNITPATH ./unitdir} produces this in verbose compiler output (fpc --vva test.pas):
[0.265] Compiling test.pas
[0.265] Searching file test.pas... found
2 137/1.056 Kb Used
[0.265] test.pas (3,2) Handling switch "$UNITPATH"
[0.265] Path "F:\unitdir" not found
...
[0.437] (TEST) Registering new unit TESTUNIT
[0.437] (TEST) Load from TEST (implementation) unit TESTUNIT
[0.437] (TESTUNIT) Loading unit TESTUNIT
[0.437] Unitsearch: testunit.ppu
...
[2.059] test.pas(5,6) Fatal: Can't find unit testunit used by test
[2.059] Fatal: Compilation aborted
Steps to reproduce:
The minimal test files for reproduction are in the attached zip for convenience. These are the file contents:
- test.pas:
program test;
{$UNITPATH unitdir}
uses testunit;
begin
writeln('Say hello, unit!');
UnitHello;
end.
- unitdir/testunit.pas
unit testunit;
interface
procedure UnitHello;
implementation
procedure UnitHello;
begin
writeln('"Hello, unit."');
end;
begin
end.
With these files in place, run "fpc test.pas" and it fails to find the unit. Run "fpc -Fuunitdir test.pas", and it succeeds.
Additional information:
I've reproduced this on a 64-bit Fedora 31, and 32-bit Windows 7 and Windows 10.
This doesn't happen when using FPC 3.0.4, so it's a regression in 3.2.0 RC1.