Delphi XE2 background IDE compiler unable to find source path

Question

I just bought XE2 version, installed the update 1 ISO, and made my Open Source projects compile with it.

In fact:

I added the source code paths of the library to the general settings IDE (for all platforms I use, i.e. Windows 32 bit and 64 bit up to now);
I compiled the TestSQLite3.dpr regression tests of our framework - no problem: EXE is compiled and all tests passed;
I've a strange issue with the IDE background compilers: even if the project compiled, the IDE displays some errors about unknown files (not in the bottom compiler messages, but in the top of the classes navigation tree - left to the source code editor), and in the .dpr source code, the unit names are underlined in red, and I'm not able to navigate inside the source (using Ctrl+Click on a symbol).

I've added the source code paths of the library to the project options (for Win32/Win64 - even if it was already set at the global IDE level). Now the errors about unknown files disappeared, but the unit names are still underlined in red in the source code, and the Ctrl+Click does not work.

The TestSQLite3.dpr source code do not specify the full path of the units:

uses
  {$I SynDprUses.inc}
  Windows,
  Messages,
  SysUtils,
  Classes,
  SynCrypto,
  SynCrtSock,
  SynCommons,
  SynDB,
  SynOleDB,
  SynDBOracle,
  (...)

In the above lines, SynCrypto, SynCrtSock, SynCommons are underlined in red.

My actual guess is that full paths are needed in the .dpr (SynCrypto in '..\SynCrypto.pas'). I did not test this because I don't have XE2 at work.

Since there was no issue with the previous IDE with this kind of source code (it worked from Delphi 6 up to XE), I wonder if there is a possibility of regression, or a new option not available with the previous version of the IDE (probably platform-based) which I did not set properly. Or perhaps the full path is now needed in .dpr - but this sounds like a regression in the Code/Error Insight compiler to me.

Still the same issue with Update 2. The common library folders are not retrieved by the background compilers. — Arnaud Bouchez
After Update 3 installation - still the same. I found a solution by getting rid of any code in .dpr and putting all files in an external unit. See synopse.info/fossil/info/ddcf953db5 — Arnaud Bouchez
hello! stumbled upon this in mORMot SAD: " The less frequent queries may be executed other separated collections" - bet you meant "over" not "other" :-) PS. Did you think about adding transactions-awareness to the replication? So that if master/slave connection drops in the middle of the large table update it would not end being half-updated? Obvious solution would be all-or-nothing, however it has its own problems over slow/fuzzy internet — Arioch 'The
one more glitch. i read online SAD 1.18 html - and in 4.1 section i click over WinAnsiString link. It redirects me to a 404 URL http://synopse.info/files/html/api-1.18%5CSynCommons.html#WINANSISTRING - notice the wrong %5C there instead of a correct slash single character — Arioch 'The
@Arioch'The I've tried to fix the doc. Thanks for the feedback! About remote connection, there is the BATCH feature in the framework which allows this automatic transaction. Even our latest master/slave replication uses transactions whenever possible. — Arnaud Bouchez

Arnaud Bouchez Arnaud Bouchez · Accepted Answer · 2011-10-03T09:03:34

I asked the question to Dr Bob (by whom I bought the XE2 license - since the 1 $ = 1 € equation sounded a bit unfair, I wanted at least to have a real Delphi expert for being my reseller).

Here is his answer:

You did not make a mistake. The problem is that the there are three compilers in XE2 (like in previous versions of Delphi): the real compiler (which works fine), the Code Insight compiler (which is faster), the Error Insight compiler (which must be even more faster), and the syntax highlighting parser (which is the fastest).

XE2 introduced a number of features that made the normal compiler slower, and gave the Code Insight and Error Insight compilers a bit of trouble. First of all, we have the new targets: Win32, Win64 and OSX which cause the search paths to be different for each target (see $PLATFORM directive), as well as build configuration, although there is only one "Library path" for each PLATFORM (and not for the build configurations).

The second complexing factor is the dotted unit names (scoped unit names) that were introduced. Windows is no longer Windows, but Winapi.Windows.

My guess is that these two additional complexing factors cause problems for the Code Insight and Error Insight compilers. Note that the real compiler still works. But the Error Insight shows incorrect errors, and the Code Insight doesn't always work for these units.

You could try to explicitly add them to the project again (in which case the full path will be used, like you mention in your question on stack overflow as well).

So I'm afraid this is some regression...

Edit at closing question:

First point is that adding full paths:

  SynPdf in '..\SynPdf.pas',

in the .dpr did let the files been found - but the background compiler is still lost, unable to find a class declaration in this body.

Just another regression sample:

   var Thread: array[0..3] of integer; 
       Handle: array[0..high(Thread)] of integer;

Is a perfectly safe syntax, compiles just fine, was interpreted by the previous Error Insight compiler without any problems (works since Delphi 5), but fails under XE2.

I'm a bit disappointed about XE2 IDE. Compiler makes it work. But IDE is really disappointing. It is not usable, from my point of view. I'll continue using Delphi 7 as my main editor, and just use XE2 as cross-platform compiler and debugger.

Delphi XE2 background IDE compiler unable to find source path

2 Answers