I usually don't show compiler progress when compiling, but I decided to turn it on.
I noticed that when my program compiles, it is also compiling the components that it uses. For example it uses Toolbar2000 (TB2K) and in the compiler progress window I can see it says compiling TB2kDock.pas, etc.
Is this by design? Is there perhaps a setting where I can tell it not to compile components every time (Since they are not changing) and only compile what is in my program's actual source code directory?
Compile is supposed to just recompile your changed units and create new dcu files. The linker always has to rebuild the Exe from the dcu files. Build recreates dcu files for all pas files whether you modified them or not.
before you look into this you have to understand that COMPILING your application and BUILDING it are two different things. As far as my understanding goes when you COMPILE the application Delphi modifies the exe and simply changes what you have changed in your applications code. When you BUILD the application it replaces the exe.
So when you build the application if will recompile all the units of the components that is listed in your settings and options, but when you just compile it (Even if it says its compiling that unit) its actually just searching for changed pieces of code in that unit that needs to be modified in your exe
I am speaking under correction of course
Related
Compiling some old code, my application will no longer run. Newly compiled exe-file won't start "because qtintf70.dll is missing from your computer".
Strange thing: an older exe file compiled from exact same code runs just fine. Both exe files tested on same system, but compiled on different Delphi installations (both Delphi 7 running on VirtualBox).
Googling, someone suggested "You have pulled in Clx somehow. Clx apps require the QT library. Look for units in your uses clauses that start with Q." but again: this is the exact same code. I've checked and can't find anything.
Suggestions?
In D7, the only source code units which reference qtintf70.dll are QForms.Pas and Qt.Pas.
So, what you need to do is to
Move all instances of these two files and their corresponding .DCU files to somewhere not on your project's search paths. Use a utility like SwiftSearch to make sure you find all of them.
Do a full build of the project.
The build should grind to a halt somewhere with a complaint that the compiler can't find one or other of these units. The source unit that is being compiled at the time is the one which contains a reference to one or other of them.
When I open my project and I double click on a specific pas file in the Project Manager, bds.exe freezes and continues using 25% of the cpu. I have to kill the process through the Windows Task Manager. (1)
When I open my project and I press F12 on that exact same file, I see what I would have expected to see earlier, the contents of the pas file.
When I open my project and I compile it first, then double click on the file, everything is fine.
I'm trying to figure out how, what I assume to be a mismatched DCU file, snuck into my project and what the best way is to prevent a similar issue in the future. Can I force all DCU files to be rebuilt? Can I simply delete all dcu files and recompile or is that a dangerous thing to do? My DCU files are currently also stored in the same directory where I keep the pas and dfm files, that is a bit messy.
(1) our application also shows behaviour in production where it sometimes crashes while it continues to use a steady cpu usage or simply continues to work as expected but shows a steady cpu usage in the background. We have been unable to trigger it in a compiled version but see it popping up from time to time. We assume the dcu mismatch is at the source of this problem.
There are numerous issues in your question, some entirely unrelated, but the assumption that the problem is a "mismatched" DCU is unlikely to be correct (by which I presume you mean an "old" or otherwise incorrect DCU compiled in the past or with different source).
First your problems.
IDE Behaviour
The problem with the IDE locking up when double-clicking a unit in the Project Manager is unlikely to be anything to do with a "mismatched" DCU.
Do you have source files located on a network drive ? Is this unit such a file ? Is that network location available/valid ? i.e. is the path to the file using a network drive letter that is no longer mapped or otherwise not available ?
If there is no explicit path in the unit reference in the DPR, do you have network locations listed in your system, IDE or project PATH ?
Difficulty accessing file locations is the most likely explanation for the IDE appearing to lock up when trying to simply open a file.
As to why it should behave differently when using F12 rather than the Project Manager, unfortunately the Delphi IDE is notorious for using different mechanisms to achieve the same thing in different places so it isn't surprising that sometimes when one of these mechanisms breaks the others still work (and can give different results even when both work).
Runtime Behaviour of your App
If we work on the basis that you do indeed have a "mismatched" DCU then performing a full build of your project will resolve that mismatch, as long as you have the source for all the required DCU's and that the correct and appropriate source for each DCU is available.
However, even though the mismatch may be resolved, rebuilding may or may not fix the issue, depending on whether that issue remains in the source code for that unit itself when recompiled.
The simple fact of the DCU being "mismatched" cannot cause aberrant application behaviour. With the exception of OS or RTL bugs etc, if there are errors in the behaviour of an application then those errors will be the result of errors in the source code as compiled.
Simply recompiling source code containing an error will not remove that error.
As such, if there is such an error then far more information will be needed if anyone is to be able to give any assistance on that score (and this should be a separate question, once you have done some initial debugging and diagnostics yourself).
Runtime Packages
If you are using runtime packages then things get more complicated because with a runtime package, the DCU employed for any particular unit could be part of a package file. In that case, the DCU file on disk is produced when you compile the package itself but any project that uses that package will not use the DCU on disk but will instead use the version that has been compiled into the package.
So if you are using runtime packages then as well as rebuilding your project you need to also rebuild any and all runtime packages that may have changed.
Now, for your actual questions.
Q1: Can I Rebuild all The DCU's ?
Yes, of course. But see above w.r.t Runtime Packages, if your project uses them.
I would strongly recommend that you change your project settings to output DCU files to a specific location, separate from the source files.
For example, you could have a project specific DCU folder using a relative path. i.e. set your DCU output folder to something like ".\dcu" and create a dcu folder within the folder where your DPR is located.
For Delphi versions supporting multiple platforms and configurations it is best to include the environment variables for the platform and configuration in that path, so that you don't end up using units compiled for DEBUG in a RELEASE build.
e.g.
.\dcu\$(Platform)\$(Config)
or
.\$(Platform)\$(Config)\dcu
What Is Compiled in a Build ?
When you do a Build on a project (as distinct from a "Compile"), all units referenced by that project will be recompiled, with the exception of any VCL/RTL units (i.e. those provided with Delphi). Those get special treatment.
At a minimum, rebuilding a project will forcibly recompile all units explicitly listed in the DPR, but will also recompile all other units that are used by those units (or units that they use etc etc).
NOTE: DCU's With Missing Source
A unit will only be recompiled if the source can be located.
If you have a DCU and the source file is missing or cannot be located on the project, IDE or system path, then the compiler will simply assume that you want to use the existing DCU.
This is the case even with a full "Build".
3rd Party DCU's
It may seem obvious but you should also be careful that you don't delete DCU's that may be your only copy of any 3rd party libraries you may be using for which you do not have the source.
This is highly inadvisable, but I guess we mustn't rule out the possibility that you may be in this situation.
Q2: Should I Delete all the DCU's ?
In general, yes. As noted above, even a full build will be successful if you are missing the source code for a unit that is referenced, as long as there is a DCU (or required package, if using runtime packages) that can be found.
So the only way to be sure that you have the current source for all DCU's is to first delete the DCU's that any previous builds may have used.
This is of course much easier when you have a specific, explicit location in which all your project DCU's are output.
It's slightly more involved if you are using Runtime Packages, though if you are organising your DCU's sensibly then the only real complication is that you need to repeat the same exercise for all the projects involved, working through starting each of the runtime packages that are used and finishing with the projects that in turn use them.
Yes, you can rebuild all DCU files in your project;
In the project group window, right click on the project and select Build.
It is OK to delete all DCUs in your project, but not necessary (or desirable in case you make a mistake...).
Note that this only builds DCUs explicitly in you project (as shown in your project tree) not any implicit ones imported as a result of your uses clauses.
Three things may be going on that have not been adressed in other answers.
Note that I only have experience with Delphi XE2 and Seattle 10, but they may apply to your version.
Delphi can be slow when switching from form to source view, especially if you have many components on your form. In migrating from XE2 to 10, we noticed an improvement here. We are talking seconds here, this does not seem to be your issue.
Delphi can be notoriously slow when switching between projects. After a switch the IDE can take a very long time (20-30 seconds) to respond. You cannot type anything; code completion takes a long time; initiating a project search with Alt-S-D waits a long time, then fails. In migrating from XE2 to 10, we noticed a large deterioration here.
Conditional compilation. If you have IFDEFs in your code compiling stuff for one project but not for another, your IDE can hang completely, and there's nothing else you can do then killing BDS.EXE. This happens in Delphi Seattle 10 if you switch projects and accidentally Compile instead of Build.
You may experience variations of these.
I have a BPL project (with some base stuff) and an EXE project which has in it's Search Path the location of the other project's output (BPL and DCP). When the EXE project is built with "Build With Runtime Packages", it builds fine. However, it requires me to deploy the EXE and the BPL. So far so good.
Since I'd rather deploy just the EXE (no matter it gets bigger), I'd guess that I'd just uncheck "Build With Runtime Packages" and that'd be it, but it's not the case. It won't build, and start complaining about the missing classes. The only way I can compile the EXE project is if I add the path to the actual BPL project's DCUs to the EXE project's Search Path. I can do that, but why am I forced to point to the DCUs? Can't Delphi just take them from the BPL? It's not just a matter of taste, if I go this way, and link to the DCU's, when it comes to DCUs belonging to forms, it will then ask me for the forms DFMs, forcing me to also include my sources folder to the EXE project's Search Path, and now it would seem as they are getting compiled, which is prohibitive. I can't recompile my BPL project codebase each time I want to compile my EXE project.
I hope I have made myself clear.
Any help on how to achieve what is asked in the title is appreciated.
Thank you.
There are two ways to link external libraries: static and dynamic.
When you are using runtime packages, this is a dynamic linking. Actual implementation is in the BPL file (which is a simple dll actually), methods and classes are imported from it on the process start. This reduces exe size, but requires BPL file to be shipped (same as usual dll). DCU files are not needed, because everything is already compiled and linked, linker need only to create import section.
When runtime packages are disabled, linker has to take object files for all classes and methods and combine it into the one executable. It could not extract this data from the BPL, because its is already linked executable. It would have to unlink it first, separating different modules implementation, which is basically impossible. So you have to provide DCU files, containing compiled object code to link your program.
So answer for your question title is simple - no it is not possible.
No, you can't. If you want to use runtime packages you have to turn on the compiler option to build with runtime packages.
As to the second part of your question:
Building with runtime packages uses the *.dcp files to compile (the .dfm streams are linked into packages' resources so the *.dfm files are not needed directly).
Building without runtime packages needs the *.dcu and *.dfm files (and any other required files).
In either case, you need to have the required files in your library/search path to be able to compile/build.
It is possible, but is very hard to implement.
And you will need to create a third project for this purpose - a loader.
You need to turn your original EXE project to a DLL built with runtime pckages.
The loader can include your DLL project, rtl.bpl, vlc.bpl and your BPL project as resources inside loader executable.
Loader will need to manually do all things that are done by LoadLibrary Windows API.
You can read more about how to load DLLs from memory and find some code samples to start with here.
I need to know if is there any option to compile a delphi project only if the source or any used unit, package etc has been changed.
If this is not possible, second alternative : Is there any option to generate exactly the same binary compiling two times the same project.
Thanks.
Edit: The usage is for a hash based WebUpdate.
A Delphi "compile" will compile only changed units. But as said, unit have data so the compiler can check which needs updating and which not. And the executable can change because the build process can rearrange the exe. Your web updates should not use a file hash, it should use version information to decide what to update and what not. That's the way installers check which files should be replaced.
Delphi compiles only changed units on a compile, and compiles all units regardless of change-status on a build.
Exe's are never the same, on a binary level. Just built a project twice, renamed the exe's to have a txt extension and compared them with Beyond Compare: it shows differences.
One (hard) solution: Make your exes using a Makefile! A makefile allows you to say "this exe is made from those files, using those commands". Make will only run "those commands" if at least one of the files you list as making up your exe is newer then your exe.
The hard part in this is setting up the list of files that make up your exe: You can easily get the list of files listed in the DPR/DPROJ, but you'll also need to identify all the linked resources ($R), all the included files ($INCLUDE), all the files that are implictelly compiled by Delphi because they're used in the "uses" clauses and are found on the Library Path.
Generating a Makefile for the general case is very difficult, but for one particular project it might work. For example you might consider your file dependent on only the files listed in the DPR files and then make sure you add all the relevant files to the DPR.
I've just noticed that whenever I do an incremental compile (ctrl-F9) of any of my Delphi 2010 projects, all JEDI units referenced in my project are recompiling although they have not been changed in any way. In fact, if I create a new project, drop a JEDI control on the form and compile, I see all JEDI dependencies getting recompiled. If I think hit ctrl-F9 a second time without making any changes in my project, the same thing happens.
Anyone know what's causing this?
Update: The problem appears to be related to the subdirectory jvcl\run on my system. All units in this folder are getting recompiled each time I do a Delphi compilation (even without touching my project source). The compiled dcus are getting and left in this subdirectory on every compilation, even though the compiled dcus already exist in jvcl\lib\d14. I do not have jvcl\run on my library path.
Additionally, if I move the jvcl\run directory elsewhere on my hard disk my project compiles and links successfully, presumably finding the dcus in jvcl\lib\d14 (which is on my path).
Sometimes you will see the unit name flash by on the compile progress screen, even when it is not being recompiled.
To know for sure, check the date of the Jedi DCU's before and after compile.
Also, how did you install the Jedi controls? If you use the default installer, then they shouldn't compile ever (they are compiled at install). If you just dropped all the source into your library path, then they will recompile on a build, or if they are changed (and various other conditions).
There are a few placed to check for your "jvcl\run" path in your settings.
The first two:
Tools|Options
Environment Options|Delphi Options|Library-Win32
(1) "Library Path:" Edit Box
(2) "Debug DCU Path:" Edit Box
The Third is:
Open Your Project
Project | Options
Directories/Conditionals
(3) Search Path: Edit Box
And finally if you compile via the command line you need to check what you are passing in the DCC32.CFG and/or PROJECTNAME.CFG and the command line parameters to DCCC32.
The reason your compiled DCU's are getting placed in directory your source is in is because you have not set an "Unit Output Directory"