[fpc-devel] Purpose of "uses ... in"?
Michael Van Canneyt
michael at freepascal.org
Mon Jul 12 08:12:31 CEST 2010
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
> 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
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
'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
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.
More information about the fpc-devel