My reason for asking: I have a folder X with source used by project A. When I include that folder under Project A's search path, it says it cannot find a specific file in that folder. When I include it under the Library path, then project A compiles fine.
Lets say that you have a thirdparty component that you use. You point the library path to the directory where the pre-compiled dcu-files of that component are. Your project will use these dcu-files when you compile. This is good, because it wont be recompiled every time you do a build.
delphi library path vs browsing path
But by including the compiled dcu files, you loose the possibility to debug the thirparty component. If you include the path to where the source files are in the browse path, the debugger will find the source, and allow you to step in to it.
Update: There are two different kind of search paths: Compiler search path and debugger search path. The first is there the compiler looks for files during compiling, and the second is where the debugger looks for source files during debugging.
The compiler will only find files in the Library path or the projects search path. The debugger will find identifiers in the compilers search path plus the browsing path, the debug source path for the project, and the global debug search path.
This is the Delphi global library path. The compiler can find only those files that exist on the Library path. If you try to build your package with a file that is not on the Library path, you receive a compiler error.
Some resource files (such as controls.res) are only available in the Release folder (not the Debug folder), so you should ensure that your project Release directory either is specified in the Library path or will be resolved by at least one variable in the Library path.
Specifies the directories where the Code Browsing feature of the Code Editor looks for unit files when it cannot find an identifier on the project search path or source path. The Code Editor searches for unit files used for code browsing in the following order:
I'm running into an issue where I pulled a project out of git into its own isolated folder tree and tried to build it. I'm getting compiler errors because there are hits on previously unknown conflicts in component libs I have in my system. Clearly there are some ordering differences in search paths.
(In this particular instance, we've got an old library from D7 era that was brought forward into DX10.2 and cleaned up so it doesn't produce the tons of hints and warnings it used to. In attempting this build, I discovered that a 3rd-party component vendor has incorporated this exact same library into their own source tree, and the compiler is finding this copy rather than the older one that's isolated and installed as a component. This newly discovered code is the older version with all of the hints and warnings from D7 days -- it was never cleaned up for newer Delphi versions. It also has some errors that stop the build. I'm trying to figure out how this folder is even being included in the library search path, as it's not in MY global search paths that Delphi loads up.)
The automated installer can automatically append some JCL paths to the IDE Library Path. These paths are iterated when the compiler is looking for a prebuilt unit (.dcu) or package (.dcp). The automated installer automatically registers the JCL library release path (jcl/lib/dXX) and the JCL include path (jcl/source/include).
These paths should not contain JCL source files (.pas) unless you exactly knows what you are doing. Otherwise, you may experience some compiler errors like "units ... was compiled with a different version of unit ..."
The IDE considers the IDE Browsing file when a source file is about to be displayed inside the editor. For instance, this happens when you click "Open File at cursor" or "Search for declaration". The automated installer can automatically register the JCL source paths (jcl/source/common, jcl/source/vcl and jcl/source/windows on Windows) into the IDE browsing path.
In newer versions of Windows, there is a nice dialog to modify the Windows path. If you are in an older Windows version (or don't like the built-in dialog) you can use any of the tools mentioned here: -there-a-convenient-way-to-edit-path-in-windows-7
In step 2 we added an entry to the Windows Path. This is not strictly necessary, the only thing that isnecessary is that FlexCel .bpl files are reachable from Windows. The setup doesn't modify the Path,because the Windows Path can't be too big. Instead it creates symbolic links from the bpls to Delphi'sbpl folder (which is already in the Path). You could create symbolic links too in the same way insteadof modifying the Windows path. But the simplest solution is just to add the folder with FlexCel bpls to the Path.
The .pas units of FlexCel belong in the Browsing Path, not the Library path. If you put the .pas units in the Library path, they will be recompiled every time you recompile your project, making your build times much slower. It will also generate lots of repeated .dcus in your hard disk for every project using FlexCel.
It gets worse: If you look at the image above, there is a button "Delete Invalid Paths" which offers to remove the grayed out paths. Never press that button. If you do, Delphi will happily remove all paths with $(Platform) on them, and you will have to restore them manually.
To remove the error we need a smaller command line, and to make the command line smaller the simplest way is to remove unused entries in the library path. But another way to reduce the command line could be to install all components to a shorter folder. so instead of installing to c:\my components\thirdparty\...\whatever try installing them to something like c:\dev.
This normally means that rsvars.bat in your installation doesn't have the correct paths. Search for rsvars.bat in the bin folder inside the folder where you installed Delphi, edit it and make sure that paths in that file are right.
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters are used here for visual clarity and cannot be part of a valid path string.)
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.
There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.
These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.
These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW. 2ff7e9595c
Comments