The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My work

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,811 other followers

When the Delphi XE5 commandline compiler fails with `error F1026: File not found: ‘False.dpr’`

Posted by jpluimers on 2013/11/20

If you an error like below when compiling Delphi XE5 .dproj files using msbuild … then note the documentation for Debug information (Delphi) – RAD Studio. has not been updated yet as it still lists the values {$D+} or {$D-} {$DEBUGINFO ON} or {$DEBUGINFO OFF}.

(_PasCoreCompile target) -> C:\Program Files (x86)\Embarcadero\RAD Studio\12.0\Bin\CodeGear.Delphi.Targets(187,5): error F1026: File not found: 'False.dpr'

With Delphi XE5, you can specify 3 additional values: {$D1}{$D2} and {$D0}, or {$DEBUGINFO 1}{$DEBUGINFO 2} or {$DEBUGINFO 0}

In the msbuild .dproj files , the values are stored as DCC_DebugInformation elements. Up until Delphi XE4, the  values could be false, False, true and True:

D0/D1/D2 in the IDE

D0/D1/D2 in the IDE

As of Delphi XE5, these values can only be 0, 1 or 2:

So the compiler in the IDE understands all 5 possibilities, but the The built-in compiler accepts all 3, but the msbuild scripts only accept 0, 1 and 2.

The major bug is that when you pass a .dproj file having the old false/False or true/True values, you get the above error.

The bug could have been resolved by the IDE to convert .dproj files correctly, but it does not replace false/False with 0, nor true/True with 1 or 2.

Note that the command-line compilers have not updated their built-in help, but the IDE allows all three values:

The reason for the change $D was changed to allow three-levels of debug information generation so the DWARF debugging part of the LLVM backend gets enough information to adequately debug your Android and iOS applications using gdb, and DWARF is the only symbol format that gdb understands.

Apple had similar extension of debug information when they started to support LLVM and DWARF.

The solution

manually update your .dproj files.

Note that this can also manifest itself in the IDE as these errors (see These kinds of errors drive me nuts!   I know this error is in the project file…. which has many other interesting tips):


13 Responses to “When the Delphi XE5 commandline compiler fails with `error F1026: File not found: ‘False.dpr’`”

  1. […] As since E1026 is [WayBack] documented as x1026 since Delphi 2007 probably because it can manifest itself as W1026 as well, I thought Delphi Error: E1026 File not found: 'Controls.res' also be related to F1026: When the Delphi XE5 commandline compiler fails with error F1026: File not found: ‘False.dpr’ […]

  2. big bad said

    So a batch replace for {$D+} to {$D2} will do the trick?

  3. Thank you!

  4. Thank you so much for this!! You just solved my problem when starting to migrate from XE3 to XE7!

  5. jpluimers said

    See also Porting to XE5 and the “W1030 Invalid compiler directive: ‘true’” warning

  6. Alex said

    Documentation is not the only thing that was not updated. IDE’s OpenTools API is not updated for this change either:

  7. Kibab said

    Bug that creates true in .dproj is in XE5(Upd2) IDE.
    I’ve migrated large project from D2009 to XE5(Upd2), but in about a week working on XE5 I have 3-4 times that XE5 IDE created that true (D2009 project is in separate branch).
    I’m don’t know how to reproduce it, because bug shows only when building with msbuild. And now, when I know that it’s not only me, then I’ll take a closer look on this :)

    Working on XE5 I see that inherinace for “Project options” is buggy (like VersionInfo, Icon, RuntimeThemes, DCC_DebugInformation) – it creates duplicated options in inherited options set.

    • jpluimers said

      Thanks for the feedback. If you can reproduce the inheritance issue for project options, let me know: I can help you file a bug in QC for that.

  8. […] In my view, the LLVM tool chain opens a lot more possibilities (shared back-end for Delphi and C++, coverage of more platforms, better optimization), but is also a lot slower and makes the debugging part a lot harder as the debugger is – symbol wise – much further away from the compiler than in the traditional setting (hence the 3 levels of debugging information that got introduced in Delphi XE5 and the compatibility problem that came with it). […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: