#569 Ota.GetAllPossiblePaths does not return the folders in the order the compiler searches them

[Thomas Mueller]

Ota.GetAllPossiblePaths (GX_OtaUtils.pas) returns the folders in this order:

1. the project's search path and the IDE's library path (Ota.GetEffectiveLibraryPath)
2. the folders of the project's units
3. the folder of the current file
4. the folder of the project group
5. every folder under the IDE's Source folder
6. the browsing path, if asked for (bug #553)

The compiler searches the project's folder first, then the project's search path, then the library path, and takes units that the .dpr lists with in '...' from exactly that file.

Differences:

• The project's folder is added first, but GetEffectiveLibraryPath starts with Paths.Clear and drops it. It only comes back, too late, if it is also the folder of one of the project's units, of the current file or of the project group.
• The folders of the project's units come after the library path.
• GetEffectiveLibraryPath is called without the Project that was passed in, so the search path of the current project is used for any other project.
• The folders of the current file and the project group, the IDE's Source folders and the browsing path are not searched by the compiler. They belong after the compiler's folders, as they only serve to find sources the compiler does not use, e.g. the source of a unit that is on the library path only as a .dcu file.

Every caller that takes the first match can therefore get a different copy of a unit than the one the compiler uses: Ota.TryFindPathToFile, Ota.FindPathToFile and Ota.OpenFileFromPath ("Open Unit" in the Uses Clause Manager and in Project Dependencies, the uses list on the editor toolbar), and Grep's search of the units in the project's map file. Example: a unit that is not part of the project lies in the project's folder, and an older copy of it is on the library path. The compiler uses the one in the project's folder, the lookup finds the older one.

The folders should be returned in the order the compiler searches them, followed by the folders that only serve to find sources.

Found while reviewing the fix for bug #553.

[Thomas Mueller]

Measured with RAD Studio 13 and MSBuild, which builds the same way as the IDE: the compiler searches the project's folder first, then the project's search path, then the library path. This applies to units and to {$I} files alike. MSBuild runs the compiler in the project's folder even when it is started from another folder, and the compiler searches the current folder before the -U and -I folders. A unit that the .dpr lists with in '...' is taken from exactly that file.

So the order the description asks for is right. One point of the description is wrong: the project's folder is not dropped. GetEffectiveLibraryPath clears the list, but GetProjectSourcePathStrings then adds the project's folder as the first entry.

What remains:

• GetEffectiveLibraryPath is called without the Project that was passed in, and the project's folder that GetAllPossiblePaths adds before that call is cleared right away.
• A unit that the .dpr lists with in '...' from a subfolder is found after a copy of it on the search path or the library path, because the folders of the project's units come after those paths. The compiler takes the file named in the in clause.