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
- 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 Delphi debug a wrong unit )
- (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 dependent package with slightly different paths in its configuration in a projectgroup) 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
- the unit is mentioned with a wrong path in the .dpr
(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.