Jonas Maebe schrieb:
That is incorrect. Relative file names do work. They are resolved
relative to the current working directory of the compiler.
So what's the "current working directory"?
The current directory when the compiler was started. E.g.:
c:\pp\src> ppc386 project\test.pas
-> "c:\pp\src" is the current working directory (aka present working directory).
Sorry, I don't understand this strange convention :-(
How can the user of a project know, from which directory a project must
be compiled, so that the relative pathes are resolved as the project
author had in mind? How in detail does Lazarus know that? But it would
explain why my relative unit was not found :-(
Does this mean that whole projects are recompiled, when only the
compiler is invoked from a different directory, so that relative pathes
are re-evaluated properly?
That's why I would restrict the usage of "in", with a (relative) path,
to a program or library module, as AFAIR Delphi does, and make the
directory of that file the root for relative filenames. In other units a
relative path, based on an arbitrary working directory, can only lead to
confusion, when the using unit is compiled for different projects -
except when the directory of the using unit itself is used to resolve
relative filenames in its uses clauses.
In other units it may be helpful when the filename can be overridden
(alias feature). Then it's easy to exchange qualified references, by
only changing the unit name in the uses clause, instead of editing all
occurences of the unit name in the remainder of the code. But this is
not a frequently required feature, so that "in filespec" simply could be
ignored (or disallowed) in ordinary units.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
