[fpc-devel] Purpose of "uses ... in"?

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> > Even for portability purposes it often doesn't work, since usually the build
> > systems  and files for FPC/Lazarus and Delphi differ anyway (and you noticed
> > the working dir difference)
> 
> The working dir difference is a Lazarus difference, not an FPC  
> difference. Afaict, that feature works identically in FPC and in Delphi.

> Furthermore, at least two of "the users" have already posted in this  
> thread saying that they use this functionality (both in FPC and in  
> Delphi). Therefore I don't think it is a good idea to remove or change  
> it.

Nobody is talking about removing ? It is more a matter of not expanding, and
not guaranteeing too much (more) wrt to it. Specially since DoDi in other
posts seemed to state that he wanted to use it to override which unit is
selected in multiple sources in path cases.

So I was not talking about IN in general, but the specific case
that it actually contains paths (IOW not unit renaming).

(btw afaik the consequences of IN (but also allowing multiple casings in
general) is that we don't use the OS routines to search for files, but read
in the entire dir ourselves? Because one full search is cheaper than many
small ones?)

> If different functionality is desired, I think it's better to add a  
> different construct rather than using the same construct but with a  
> different meaning.

The whole paths in source is evil IMHO. It should not be expanded. The IN
should remain what it was introduced for, a minimal ability to work around
some case problems, and nothing more.