I already asked how to upgrade to the latest Indy TCP TP components version ( GET INDY COMPONENTS ) and Installed Indy 10 with DELPHI XE 2 now. For all the Indy projects I defined an outfolder in the project options section of DELPHI XE2, here I found later all the the .bpl files and all the -DCU#s files I need now in order to compile my application using the new INDY components to add this output folder as a library search path in these projects.
I found at my XE2 installation a path/folder with *.dcu files for x32, x64, release and debug mode (C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\lib\win64\release).
Do I need now all the INDY *.dcu I have created also in these different flavours compiled, how to set the path for all project to use the new *.dcu from my folder ?
Should I copy all my dcu's to these many sub folders ??
You should not replace the pre-installed Indy files with the updated compiled files (in case you need the originals in the future, such as for DataSnap projects). Install the newer Indy into its own separate folder, then update the projects search paths to refer to that installation's output folder(s) instread of the pre-installed folder(s).
You should not overwrite the .dcu files that are part of the Delphi installation. What's more, I would not recommend that you do anything with the .dcu files that you used to build these .bpl files.
What you should do is to include the Indy source files, the .pas files, in your project. Personally I prefer to avoid using a search path to achieve that and instead simply add all the necessary .pas files to the project. But you may prefer to use the search path option.
But the main point is that since this project is supplied in source form it is best to compile the source yourself, as part of your project. That makes it much easier for you, whilst debugging, to step through the Indy code. There's no need to have separate DCU files for release and debug. It makes the build process simpler, only one thing to build. It makes it easier if your source code targets multiple Delphi compiler versions.
Related
I am migrating from Delphi 2009 to Delphi 10.4 Sydney and I am updating the convention that I will use for the organization of my Delphi custom packages.
To see how the things should work in Delphi 10.4 Sydney, I installed 'LockBox2-2021.05-Sydney' with standard GetIt package manager that comes with Delphi, that is recent addition to Delphi and that appartently defines the best practices/conventions how the packages should be used and installed.
These are my observations:
GetIt copy complete package project to the BDSCatalogRepository (there is such Environment variable now) directory, e.g. C:\Users<ME>\Documents\Embarcadero\Studio\21.0\CatalogRepository\LockBox2-2021.05-Sydney\ and there is one common directory (/source) for the .pas/.dfm/*.fmx files and separate directories for the compiler-version-dependent project files (e.g. \packages\Sydney\Delphi).
GetIt installation adds the source directory ($(BDSCatalogRepository)\LockBox2-2021.05-Sydney\source\ in this case) to the 'Tools - Options - Language - Delphi - Library - Library path'.
Any Delphi project sees complete Library path (that now consists of the immeasurable number of source directories for the different packages projects) and if any *.pas unit of my Delphi project references any *.pas unit from the Library path, then Delphi compiler recompiles this *.pas unit from the library path and puts the resulting *.dcu in the the project 'Unit output directory' (that can be specific directory under the project folder).
This works and this seems to be the standard way of doing things for Delphi 10.4 Sydney. But it is a bit strang, I should acknowledge - each Delphi project recompiles the dcu for any package it uses. Is it good practice? Should I accept this practice? Why not accept? Maybe such recompilation overhad is not necessary, is there reason for such recompilation each time?
My understanding is that the definition of "library path" was a bit different for the Delphi 2009 ("Tools - Options - Environment Options - Delphi Optios - Library-Win32 - Library path": we usually organzed our packages in a way that put compiled *.dcu units (from the source code of packages) in one common directory, e.g. D:/Library/Delphi2009 and then we put this D:/Library/Delphi2009 into "Library path" and any custom Delphi project was able to see that the *.dcu units from the pacakges was available and visible from the library path and any Delphi project could access these dcu units from D:/Library/Delphi2009, so, there was no need for Delphi 2009 to recompile the packages *.pas files into packages *.dcu units each time when any Delphi 2009 project use that package/component.
So - this is really strange redefinition of the meaning of the "Library Path" - it was the directory for .dcu units in the Delphi 2009 times and now (Delphi 10.4 Sydney times) it is the directory for the packages/components source files (.pas) that are commonly visible to each project and that each project uses for compiling its own *.dcu units for the packages/components.
Does really such redefinition of the meaning of "Library path" happened and should I really put my component/pacakge source in the directories that I should include in the "Library path" and should I really ask Delphi compiler to recompiler dcu units (of packages/components) for each of my custom Delphi project?
Of course, formally my question contains multiple questions, but these are just details to the general question about the best practice/standard how to organize packages in the the Delphi 10.4 Sydney and beyond.
Your look at what has to go into Library Path is correct. Most libraries follow this approach and put the path to the platform dcu into Library Path and the debug dcu path appropriately. It seems that at least some of the TurboPack libraries break this convention and put the source path into Library Path. This may be convenient as you don't have to copy the dfm files to these folders, but it is definitely the wrong approach. I suggest filing a report for that.
I want to create *.bpl file but I am failing to do so.
Specifically, I am trying to make JEDI plugins, but I have tried an empty pure Delphi package, too.
If I create a new package in Delphi XE3, I get an empty unit - if I "make" this project called "Package1.bpl", I get a .dcu file in "debug/win32/", but no .bpl file.
No error is reported by the compiler.
An empty JEDI plugin (bpl-style) only gives a .dcu, too, while an empty dll-style JEDI plugin gives a .cdu and a .dll file in "debug/win32/".
This is the first time I am trying to make a new package, so I am completely lost.
What am I missing?
Go to the Tools menu and navigate to Environment Options -> Delphi Options -> Library.
There you find the Package Output Directory and the DCP Output Directory. These directories are the default output directories for BPLs and DCPs, so the bpl will be created if your packages is compiled, but in a different directory from what you expect.
The JEDI plugins probably have their output directory configured otherwise in Project -> Options.
For those that don't want to travel into Delphi IDE/options etc, lately in Delphi XE it's something like this:
"C:\Users\Public\Documents\Embarcadero\Studio\17.0\Bpl;"
Your exact folder might be different based on 17.0
These folders also end up in the path environment variable of your system, bit dangerous and can lead to some mighty magic loading confusion ?!
"How's that BPL still loading after it was deleted from my local project folder ?" :)
Another solution is to add "." to your project settings without the "". Prevents you from having to modify your delphi environment options/settings, something you probably never want to do since JEDI and other projects may rely on these default settings to function properly. Only change it if you know what you are doing and how to correctly make JEDI and others work if it was changed, this may get tricky/hairy, probably requires search paths to be added.
Currently I have not set any specific output directory for Delphi DCUs in my main project. This results in the DCU files ending up in the same directory as my .pas source files. To me, this feels ugly as I don't like the idea of mixing .pas and .dcu files in the same directory. What is the best practice for storing Delphi .dcu files - keep them all one directory for each project? Or maybe create one DCU directory for each source folder? Any ideas welcome.
The best way to do it is to create a DCU folder for each project, especially if you have more than one project that uses the same files. Otherwise, you can end up with different compiles with different compiler settings stomping each other's DCUs.
.dcu's are also dependant on defines, and e.g. debugging vs release configuration (*).
(*) While Delphi XE allows to put the "configuration" in the output path, IMHO that cure is worse than the problem
So I regularly recursively delete all .dcu's from the root of the dir where I do all my SVN checkouts.
The directory with components has a delphi version suffixed, and is outside the SVN checkout directory.
Agreed...mixing PAS and DCU files in the same directory is 'dirty'.
Whenever you start a new application, dll, or other Delphi project, one of the first things to do is to set the output directory. In later versions of Delphi this is done for you as the output directory is set as .\$(Config)\$(Platform) which correlates to the Debug or Release config option and Win32 platform. (Ending up with a default output directory of Debug\Win32)
If you build with custom compiler defines then it would be wise to have different project build options to include separate output directories for each set of custom compiler defines otherwise you have to do a full build to ensure that units are built correctly.
This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...
I have lots of components that worked perfectly under D7.
I managed to compile and install them by dragging them into the Delphi 2009 IDE.
However, when I try to use those components in a project, the compiler says it cannot find the source code of them.
Where I can enter the path to that library?
Solution:
I dragged and dropped the old DPK file in Delphi 2009. Then in project manager I choose “Build” an then “Install”.
Everything worked smoothly except that the applications that used the controls couldn't see its source.
Problem solved by adding the path into the Tool-Options-Library Win32.
Thanks to everybody and especially to Mohammed.
Have you added the source path of the components to your library path?
you can add it from Tools menu > Options > Library win 32 >Library path
If you've really installed them, then the compiler shouldn't need to find the source code. The compiler only needs the DCU files.
But if you've taken these components from Delphi 7, then you need to have the source code, because Delphi 7 DCU files are not compatible with Delphi 2009. (The only two versions ever that can use each other's DCU files are Delphi 2006 and Delphi 2007, and then only with certain restrictions.)
Trying to use DCU files from the wrong Delphi version will cause Delphi to try to recompile the units. The solution is not just to provide the path to the source code, though. If the units files haven't been compiled yet (and they obviously haven't if they're of the wrong Delphi version), then you haven't really installed anything. Installing components in Delphi has never involved dragging and dropping. Installing a component means installing the package that contains that component, and installing a package often means opening the DPK project file and then choosing the "install" command in the IDE.