My project setup looks like this:
There are multiple runtime packages. I'm not using design time packages.
Each runtime package has its DCP, package and unit output directory set to .\Library\$(Platform)\$(Config). I'm not outputting them to the global IDE locations to gain co-installability of different versions of the packages.
Also there is a Pre-build event in each package that calls a script file which copies all the dfm files from the source folders to a directory called .\Library\Dfm.
In order to build dependent packages and executables I add the output paths for the dfm and the other files to each dependencies local search path, for example:
..\Package1\Library\$(Platform)\$(Config)
..\Package1\Library\Dfm
..\Package2\Library\$(Platform)\$(Config)
..\Package2\Library\Dfm
..\Package3\Library\$(Platform)\$(Config)
..\Package3\Library\Dfm
Technically I only need to add the Dfm directories to the final executables search path since dfm files are linked into the PE executables resource section.
Still it seems like an unneccessary extra step to have two paths for each package.
So I am asking: Is it possible to link the dfm files into the bpl file for each package instead of the final executable?
One problem I can think of myself is that this would only work when runtime packages are enabled for the executable, because the compiler couldn't move the resources from the bpls to the exe otherwise?!
Is it even in principle possible to have the dfm resources in a different module than the one of the executable?
When compiling an executable with runtime packages enabled the compiler does not need access to the dfm files for forms inside the packages.
They are indeed linked into the bpl files.
When compiling with runtime packages disabled the compiler complains about the missing dfm files. So it apparently can not pull the resources from the compiled package file (bpl).
Related
This issue is driving me crazy. I'm trying to compile and install The QR Designer from QuickReports 6. I have an issue just with the one package. When I right the package in the IDE > Install the IDE gives me:
Can't load package C:\xe10_3\QRDesign\Win32\Debug\dclqrd_DXE10_3.bpl.
The specified module could not be found.
But the exact file is there.
I've also tried installing it via the menu under Components > Install Packages and then choosing the BPL from there, with the same issue.
I've tried to use Process Monitor as on this post here to find the issue:
Delphi Can't load package the specified module cannot be found
I couldn't fix the issue, but what I did pick up from Process Monitor was that some process was looking for the package here:
Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Package Cache\dclqrd_DXE10_3.bpl
That key didn't exists. I tried manually creating the key, but that didn't do a thing.
Any ideas?
UPDATE
Here is the list of packages:
As you can see, dclqrd_DXE10_3 is dependant on two others. Which I already built and installed. I removed its references and re-added them again now, to make sure the references are sound. I guess its like Remy said, the Specified module not found is probably not referring to dclqrd_DXE10_3 although I don't know what other module it could be referring to.
To install a package successfully in IDE, follow the steps:
Open the dpk/dproj/groupproj file in IDE
Build the package(s) for Windows 32-bit platform.
IDE itself is a 32-bit applicaton, so it should match.
Normally, it will build all dependent/required packages
Check if all chain of BPL & DCP files are generated in package Output directory.
It defaults to $(BDSCOMMONDIR)\Bpl & Dcp folders, but can be changed individually for each Package in Settings.
PBL packages are like DLL files. In order to load them, it requires all dependent BPLs.
If you have custom package output paths:
Check if your DCP output path is included in Tools\Options\Language\Delphi\Library Library Path for Windows 32-bit platform
Check if no duplicates of outdated compiled packages in default $(BDSCOMMONDIR)\Bpl & Dcp directories
Add the paths to library source pas files in Tools\Options\Language\Delphi\Library Browsing path or Library path
In some specific cases, if the package requires some extra dll-s like DB Client libraries, check if these dlls are 32-bit and are loadable, like included in %path% environement variable.
Note, some libraries offers package installer tools, that automagically do all mentioned things for you.
Also, there are universal package installer tools for quick working environement setup in one click.
I don't know why this fixed my issue, but it did.
The output directories for the bpl and dcp was set to be $(Platform)\$(Config)
The project files for the different packages exists in the same folder so the above config was supposed to be the debug folder or the release folder. Why only this package was thrown off I still don't know, but since changing the above packages to have a fixed path suddenly I could now install dclqrd_DXE10_3.bpl.
Thank you all for helping.
I've installed latest Jedi VCL for Delphi (JVCL 3.49) using install.bat (from jcl and jvcl folders respectively), without errors. The problem is when I run Delphi 2010, I get a lot of errors about invalid entry point in jvcl bpls.
entry point invalid #jclsysinfo#jclcheckwinversion$qqrri in JvCore140.pbl
I get this error in all Jv*.bpl files, and always with the same entry point.
I've checked I don't have old jcl/jvcl files or jv*.bpl/jc*.bpl files. I don't know how to fix this problem. Any sugestion?
When compiling packages in Delphi (as the JCL and JVCL do) that require other packages at compiletime the compiler uses the dcp files for the required packages and not the bpl files of those packages.
For example the JvCore.dpk has Jcl and JclVcl in its required clause among some RTL packages. That means when compiling it will take Jcl.dcp and JclVcl.dcp to get the information where the procedures/classes it needs are located in the bpl.
These dcp files are most of the time (unless specified differently - see next paragraph) located in the DCP folder which is right next to the BPL folder.
If the dcp it uses is not compatible to the bpl it finds when loading you will get those errors. Make sure you don't have any old bpl and dcp files anywhere that the compiler may find. In the JCL setup you can specify where it puts those while the JVCL setup puts them into the same directory as the dcu files.
Additionally if you have different Delphi versions installed it can get worse because usually the dcp files don't have a suffix. If the directory it puts those happens to be in the PATH variable wrong versions might be found. However the DCP directory is not put into PATH by the Delphi installation but only the BPL directory.
(While I've been writing this, Stefan Glienke has posted an answer which has a lot more useful info in it, but I'll post it anyway because it's easy to test if you're only interested in one Delphi version)
I'm not sure the following will work for you because I don't have D2010
installed to test it against. You could check it out quite quickly by
trying it using only one .Dpk file in step 4.
Note that I always set the Output paths for BPL,
DCP and DCU files to a Lib2 folder under the Delphi version's install folder.
That way I know where they all are so it's easier to tidy up if something goes
wrong.
I uninstalled the JCL and JVCL and deleted all the JV*.BPL, .DCP and
.DCU files
I ran the JCL install .bat, and ignored all the prompts to add folders to
the system PATH, because my Lib2 folder is already on the PATH.
In the folder for my Delphi version below JVCL\Packages, I edited all the
.Dpk files to use my Lib2 folder for the BPL, DCP and DCU output files. this is
a bit tedious but only needs to be done once and can be made easier by doing it
using a keyboard macro.
Then, using the IDE package tool, compiled and installed all the JVCL .Dpk
files that have "Design" in their names and that I want to install.
They all installed without ther error message you are getting.
Every BPL-related question found by me in Internet refers to some BPL already shipped with Delphi or at least installed globally, into Delphi folders.
I would like to make my own application to find a run-time BPL file made by me, without saving global paths anywhere, without registering my package in Delphi globally. Only put BPL file into "packages" subdirectory, define search path and compile.
Project Options
Delphi Compiler
Search path: I defined relative path to my BPLs (packages folder) here
Packages
Runtime Packages
Link with runtime packages = True
Runtime packages: defined my BPL's name here, without extension
The problem is that compiler can't find my package although I have added the packages subdirectory to Project Options.
How to make it find my package?
The compiler doesn't need your BPL file. It needs the corresponding DCP file, as well as the DCU files for the units you use. Make sure those files' directories are on your search path, and your project should compile fine.
When I install a package in the IDE and use it in a project, it gets recompiled (DCUs are replaced) everytime I compile my project.
I can't imagine that this is intended - the RTL and VCL are not compiled each time either, are they?
I have played a bit with the paths in Tools > Options > Environment Options > Delphi Options > Library, but without success.
I have found a construction allowing compilation of my project without recompiling the package having DCUs and PASs in diffenent paths, but in this construction Delphi is not able to locate the sources at all from the Code Editor (SHIFT-clicking for example), so this is not an option.
To avoid recompilation you have to have separate folders for .dcu files and .pas files.
Usually this is done by settings the output dir in a package contained in the library. You build the package and it will produce the .dcu files in a output folder that is different from the source folder.
To use the package you then:
have to point the library path to the output folder (with the compiled .dcu files).
can optionally point the search path to the source folder (with the .pas files).
This gets a little more complicated when you have .dfm files in the package as well.
Every .pas file that the compiler sees in the library path is recompiled. (Actually only the last instance, because you can have the same unit in different directories that are listed in the library path).
To enable IDE features like CTRL-click you have to set the {$Y+} compiler switch in your package which can be done in the IDE Compiling options:
http://docwiki.embarcadero.com/RADStudio/XE4/en/Compiling#Debugging_Options
I'm starting with Delphi XE5 and I would like to split my application in one exe and multiple reusable libraries. That means I don't want to split the running *.exe application in DLLs or runtime Packages.
To achieve this, I have seen that in delphi we can create runtime packages and I followed the following steps:
I have created a new VCL Forms Application project (EXE project).
I have added a new Package project (BPL project) to the project group and I have modified its project options to set usage options to 'Runtime only' and build control to 'Explicit rebuild'.
I have added a dependency betwen the EXE project and the BPL project (EXE project depends on BPL project).
Finally I have compiled the BPL project and added the generated DCP file as a runtime package in the EXE project (Project options/Package/Runtime Packages).
But when I add a reference on the EXE project to use a module (moduleX for example) from the BPL project, compiler give me an error like this:
[dcc32 Fatal Error] ModuleX.pas(7): F1026 File not found: 'C:\DDDProject\MyEXEProject\ModuleX.dcu'
If I mark as checked the 'Link with runtime packages' option in the EXE project (MyEXEProject) the solution compiles without errors but I can't run or debug the application.
Please, can anyone help me?
I don't want to split the running *.exe application in DLLs or runtime Packages.
Runtime Package BPL files are DLLs. That is what allows them to be shared amongst multiple EXEs. They are just normal DLLs with special VCL/FMX handling built in.
When you enable the "Link with runtime packages" option, you are linking the EXE file to your BPL file (or DYLIB or SO file, if compiling for platforms other than Windows), so you MUST distribute the BPL file (and any other BPL files it depends on, like rtl190.bpl and vcl190.bpl) with your EXE file. So they have to be in the EXE's folder, or at least in the OS search path, in order for the EXE to run.
When you disable the "Link with runtime packages" option, your package's code is statically linked directly into the EXE file, so you need to make sure the EXE project's search paths include the folder were your package's DCU file(s) are located.
If you want to create a reusable library but not a BPL, then create a Static Library (a LIB file) instead of a Runtime Package. You can then add the LIB file to multiple projects as needed.