What is the difference between compiling and building in Delphi?

Question

With Delphi-6 there are two options: Build and Compile.

I know when I run a program it compiles only the files which have changed and uses the DCUs for those which haven't. When I click build apparently it rebuilds the DCUs.

What I have been wondering is, when I make a program for release (changing build settings, conditional variables, etc.) can I just compile, or do I have to do a full build?

What happens if I don't do a full build, is there any consiquence?

Answer 1

You should always Build when changing settings.

The previously compiled DCU files may have been compiled with different settings, such as compiler defines. Which can cause two units in the same project to be compiled with different settings.

Answer 2

@Daisetsu, here is the difference between build and compile.

Build compiles all used units in an project when the source code is available.

Compile compiles only changed used units.

in my personal experience when you make changes to the configuration of the compiler, you must execute a build of the application, so that changes will be reflected in all units of the project.

Answer 3

When build, when compile?

The compiler only automatically recompiles units when the datetime stamp of the .pas source files changes (1,2).

On other state changes in the project (directives, debug or other compiler settings etc), the compiler won't automatically recompile. That's when you need to force a build.

You also need to force a rebuild when .inc or other included ($I) files change(3), since their datetime-stamp is not checked.

So in summary, when anything but the unit .pas files changes, you need to do a build.

There are some strange cases in building. Most result in a "can't find unit xxx" error while it appears to be there

1. one is when the path of the unit in the project is wrong, or uses a relative path while the working directory is wrong. (see http://stackoverflow.com/questions/2603077/delphi-debug-a-wrong-unit/2603410#2603410 )
2. (I'm not entirely sure about this one, it is a hypothesis) a .dcu is recompiled because of the CRCs (1), but the newly compiled dcu is placed in a different directory. This is not a problem for the current compile (since the correct dcu is already loaded), but in a subsequent compile (e.g. a dependant package) the old dcu file is found again, and the source not -> error. in case of doubt always clean your build dirs by recursively deleting all DCU's

(1) and if Delphi is like FPC, .dcu's contain a CRC of the interface section of all dcu's it depends on. This can be used to check if there is an additional need for recompiles too. E.g. due to filesystem manipulation (moving dcu's about)

(2) for the experts, have a look at {$implicitbuild xx} too

(3) contrary to Delphi, FPC does rebuild on .inc changes. The FPC project heavily uses .inc files internally, this change already dates from before there was Delphi support. As a result, packages that copy the "defines" inc file into any directory won't compile with FPC because they have usually slightly different size and CRC. Indy (10) is a good example of this.

Answer 4

When preparing a release you should most certainly do a full build.
There is no excuse not to, Delphi's compiler is quite fast enough.

Clarifying Importance of Reproducible Release

• When preparing a release you will have a version of your product that other people will be using.
• If they report issues, you may need to go back to that version to test & fix the problem.
• If you did not do a full build, but instead relied existing DCU's there is a chance that one of your source files did not get recompiled.
• Even if that possibility is rather slim, that chance can seriously hamper your ability to resolve the issue quickly.
• This problem gets worse as a system gets larger, has more inter-dependencies, and has more versions 'supported in the wild'.

For your own sanity, I strongly urge that you always do full build for a releasable version.
I regularly do full builds even for non-releasable versions.