This is an excerpt from my "Delphi in all its glory - Libraries"
$(Auto) is a new environment variable, introduced in Delphi 10.4. Embarcadero didn’t make a big show around it so it went unnoticed by most programmers. But don’t ignore it! It is extremely useful for packages, where it can be used as an automatic version suffix in the package’s name.
How does it work?
$(Auto) will be automatically substituted by Delphi with compiler’s version number:
- “270” for Delphi 10.4
- “280” for Delphi 11
- Etc.
When used in the Lib Suffix field, Delphi will automatically add the compiler version number at the end of the BPL name.
For example, if my Light Saber package is named LightSaber.DPK, without this automatic suffix, the binary files will be called LightSaber.BPL (and DCP). The name will be static no matter where I compile the library (Delphi Sydney or Alex). So, if I have two Delphi versions installed in parallel, the resulted BPLs will have the same name and we would not know which is for which Delphi version.
But with the auto suffix the output file will be called LightSaber270.BPL under Delphi Sydney and LightSaber280.BPL under Delphi Alex.
Without $(Auto), we would have to manually update the right version suffix with each new Delphi release, or we would need packages with different names (LightSaber270.DPK, LightSaber280.DPK, LightSaber290.DPK, etc).
Note that when we use the LightSaber library in the requires section of another package, we specify it under its standard (non-suffixed) name. Delphi Sydney will correctly look for a file named LightSaber270.bpl and Delphi Alex for LightSaber280.bpl.
Requires
VclSmp,
Vclwinx,
LightSaber; // not LightSaber270 !
Using a library with multiple Delphi versions
There are multiple reasons for installing and using multiple Delphi versions in parallel:
- Testing a new Delphi release to see if it is worth purchasing it.
- Testing a new Delphi release to see if your code still compiles without issues.
- For library developers, testing if your library compiles with all (new and old) Delphi versions where you want to deliver/sell your library.
Hint: if you purchase a license for a specific Delphi version, you have automatic access to all versions below that.
With the four environment variables described above, we can have fully automatic naming for the output files. Each DCU file will go to the correct output folder and each BPL/DCP file will be correctly suffixed.
Now we can truly have multiple Delphi versions installed and functioning in parallel.
Library paths
When compiling a package/project, the compiler can easily find project’s units, because they are clearly listed into the DPK/DPR file. But the compiler also needs to find its “own” libraries (RTL and VCL), and also the files belonging to 3rd party libraries (if we use any).
The “Library path” is the field where we can enter the above-mentioned paths. Usually, we should input folders that contain pre-compiled libraries here, not PAS files!
There are three types of paths that we can enter here:
- Delphi’s libraries
- Third party libraries
- Our own libraries
1. Delphi libraries
If we open the “Library” dialog (Main menu -> Tools -> Options -> Language -> Delphi -> Library) we will see that the Library Path field already contains some paths. These are the folders containing the precompiled DCUs for the VCL and RTL libraries. We talked about precompiled DCUs in the previous book but we will expand the subject here.
These paths are added here by Delphi’s installer, during installation. Don’t touch them or you will fuckup the whole Delphi and you will have to reinstall – unless you have a backup of the appropriate registry key, which is:
KEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Library\
2. Third party libraries
If you install 3rd party libraries using their automatic installers, you will see their paths here. If you have favorite 3rd party libraries (for example LightSaber 😊) that don’t have an automatic installer, you will have to enter their path here, manually.
Here are the paths for the 3rd party libraries from my computer:
As stated above, only the folders containing precompiled units (DCU files) should be listed here.
A little help from GExperts
Only a few libraries have an automatic installer. Most libraries will have to be installed manually, so you will visit the “Library Paths” page quite often.
Since 2021, there is a new GExperts module that extends functionality of the IDE to allow us to enter multiple library paths at once. We don’t have to insert the paths one by one anymore like in the past! This is useful when we reinstall Delphi, and we want to restore all paths from a backup file. To use this GExperts module, just switch from the classic “List” mode to “Memo” mode as shown below:
This GExperts module is not active by default. To activate it, see the go to “GExperts configuration” page:
3. Our own libraries
Finally, if we build our own library, we will have to add its path here. Example from my computer:
Do we really need Library Paths?
What happens if we want to use a routine, let’s say the cGraphRotate.RotateBitmap from the “Light Saber” library in one of our new projects, and the path to the Light Saber library is not present into the “Library paths”? The compiler will not be able to find the Light Saber cGraphRotate.dcu that contains the RotateBitmap function.
Remember: The folder we must enter here is the folder containing Light Saber’s precompiled files, not the PAS files:
C:\My projects\LightSaber\DCU
C:\My projects\LightSaber\PAS
If we add into the Library Path the C:\My projects\LightSaber\PAS folder, the compiler will find the PAS file and compile it. We should avoid that if we want to take advantage of the precompilation.
Alternatives
An alternative way would be to link the Light Saber file (cGraphRotate.pas) directly into our project (into the DPR file). Simply drag and drop cGraphRotate.pas into the Project Manager. The compiler will now be able to find cGraphRotate.
But this approach has two issues:
1. It will solve the problem only for this project. If we start a new project, we will have to link the Light Saber to that new project again.
2. Light Saber’s files will be compiled every time we compile our projects. This is useful when we want to debug the files of a library or when we often change that library. But otherwise, and especially for large libraries, this alternative method could slow down the compilation process a lot!
Remember: One should avoid adding folders that contain Pas files into the “Library paths”. I see no valid reason for ever for doing this. If you find one, let me know.
