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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
