Retrying Try Blocks Inside Concurrent Targets
Problem
If copies of a single Target is running concurrently inside an Try block with Retry enabled, then the retry count will not be properly updated. This can lead to retries being run an unspecified number of times. Although it should never retry indefinitely, it is possible that a Try block will fail without ever being tried.
This issue does not appear when you are simply using different Retry Try Blocks in parallel, or inside different Targets. The build must be running multiple copies of the same Target.
Workaround
Do not use retry try blocks inside Targets which might be run concurrently (single action retries will work fine).
Embarcadero Delphi Compiler Action
Problem
Compiling Projects with UNC Paths in the project file property will result in the resource file not being linked into the executable. This is appears to be a bug in the Delphi command line compiler (not yet confirmed).
Workaround
Build locally, not on a network drive, or use the Map Network Drive action to create network file paths without UNC pathnames.
Wise InstallMaster/InstallBuilder Actions
Problem 1
The Wise compiler (versions earlier than 9.02) do not return a non zero return code when an error occurs during compilation. This means that FinalBuilder has no way of detecting if the compile of the installer failed or not. Usually Wise displays a message box when an error occurred.
Workaround 1
Stop the build manually after the message box is displayed.
Problem 2
The Wise compiler will hang if you attempt to run it as part of a scheduled build. This is a known problem with wise, not with FinalBuilder! The issue is that the Wise Compiler will display a message box or dialog and of course there is no way to respond to it while it is being run unattended.
Workaround 2
Enable the "Monitor for Error Dialogs" option (only available on the Properties view for an action). This option will close the dialog that is shown and fail the action. This problem may be solved with Wise 9.02, however we have not confirmed this.
Embarcadero C++ Builder Action
Problem 1
Some static Lib projects will not link correctly when compiled from FinalBuilder. You might see something like this :
J:\Embarcadero\CBUILD~1\bin\..\BIN\TLib /u debug\jpegD.lib @MAKE0000.@@@
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.@@@'
** error 1 ** deleting debug\jpegD.lib
MAKE failed, returned : 1
Workaround 1
In some cases (where the "Bad file number" error is seen) it may be possible to work around this by specifying -tDEFLIB.BMK in the BPR2MAKE Options field, and Turning off the "Capture Make Output" option.
Problem 2
Some projects (especially those migrated from an earlier version of BCB) may not compile in FinalBuilder, even though they compile fine in the BCB IDE. Typical symptoms include Unresolved External symbols errors.
Workaround 2
This work around works in some cases, where the package/libraries/sparelibs options in the bpr/bpk file are not correct. Open the project in the BCB IDE, and change the Use Packages option and save the project. Then change the Use Packages option back to what it was before, and save the project. Close BCB and attempt to build the project from FinalBuilder.
Problem 3
Make fails with the following error :
Error E2266: No file names given
MAKE failed, returned : 1
The most common cause of this a space in the intermediate output path. Make does not like this, even the mak files generated from the IDE will fail to build correctly.
Workaround 3
The only way around this is to not use intermediate output paths with spaces in them.