On Mon, 12 Jul 2010, Hans-Peter Diettrich wrote:
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?
Of course. This is normal ? The compiler may find a whole different set of units
if unit paths are relative. It may find units it didn't find in the first place.
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' is only allowed in projects, libraries and packages.
Anything else will lead to confusion.
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.
It must be disallowed. It will only be a source of frustration.
The 'in' feature was introduced by borland because they made the mistake of
using the main program file as project files. In later versions they corrected
this, but the damage was done.
The unit alias feature was introduced to ease transition from TP for windows to
Delphi.
So for historical reasons, FPC is stuck with the 'in' clause, when in fact it
should
not exist in the first place. I would not encourage it's use; the proper way to instruct
the compiler where to look for units is using the -Fu switch.
Michael.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
