Ich versuche HeidiSQL und dessen abhängige Komponenten mit der Kommandozeile (dcc32.exe) zu kompilieren und habe folgendes Problem:

Eine Unit, in der ein {$I SynEdit.inc} steht, referenziert in der USES Klausel eine andere Unit, die wiederum das gleiche {$I SynEdit.inc} enthält. Das erste "Include" macht keine Probleme, aber beim zweiten bekomme ich ein

Zitat:

(...)\compilers.inc(432) Error: E2029 'INTERFACE' expected but end of file found

Diese compilers.inc wird in der SynEdit.inc "included".

Ist die Meldung darauf zurückzuführen, daß ich in einem Include-File wiederum ein anderes Include-File einbinde (Verkettung)? Oder ist es ein generelles Problem mit der USE-Klausel?

Zu erwähnen wäre noch, daß beide .INC Dateien nur Compiler-Direktiven enthält - hauptsächlich DEFINES und ein paar Schalter.

Zitat von anse:

Ist die Meldung darauf zurückzuführen, daß ich in einem Include-File wiederum ein anderes Include-File einbinde (Verkettung)? Oder ist es ein generelles Problem mit der USE-Klausel?
Zu erwähnen wäre noch, daß beide .INC Dateien nur Compiler-Direktiven enthält - hauptsächlich DEFINES und ein paar Schalter.

Du kannst beliebige *.inc Files schachteln. Das ist kein Problem.

Der Compiler bindet die inckludierten Dateien genau an der Stelle ein, wo der Include Befehl steht.
Du kannst also auch den Inhalt der Include Datei kopieren und an der Stelle einfügen.
Das ist für den Compiler das selbe.

Man lagert gerne Compilerschalter in *.inc Dateien aus, da diese in einem Projekt manchmal in viele (alle) Dateien eingebunden werden. Es ist dann bei Änderungen an dem Inhalt der *.inc Datei sehr bequem, da nicht alle Dateien geändert werden müssen.

Zur Fehlerdiagnose kannst Du ja mal den Inhalt direkt in die Unit einfügen (an genau der Stelle wo der include Befehl steht.

Beim Compilieren sollte nun der gleiche Fehler auftreten.

Vieleicht wird Dir dann klar warum der Fehler auftritt.

Da ich weder HeidiSQL noch SynEdit kenne kann ich Dir nicht mehr helfen.

Du hast mir schon geholfen! Die Includes in die Units einzupasten hat mir nun wenigstens die genauen Zeilennummern gebracht. Das Problem besteht allerdings weiterhin:

Zitat:

(...)\SynEditMiscProcs.pas(512) Error: E2029 'INTERFACE' expected but identifier '_6' found

SynEditMiscProcs.pas (Zeilen 500 - 520):

zusammenfalten · markieren

Delphi-Quellcode:

{$IFDEF CPPB}            {$DEFINE SYN_CPPB}            {$ENDIF}

{$IFDEF CPPB_1}          {$DEFINE SYN_CPPB_1}          {$ENDIF}
{$IFDEF CPPB_3}          {$DEFINE SYN_CPPB_3}          {$ENDIF}
{$IFDEF CPPB_3_UP}       {$DEFINE SYN_CPPB_3_UP}       {$ENDIF}
{$IFDEF CPPB_4}          {$DEFINE SYN_CPPB_4}          {$ENDIF}
{$IFDEF CPPB_4_UP}       {$DEFINE SYN_CPPB_4_UP}       {$ENDIF}
{$IFDEF CPPB_5}          {$DEFINE SYN_CPPB_5}          {$ENDIF}
{$IFDEF CPPB_5_UP}       {$DEFINE SYN_CPPB_5_UP}       {$ENDIF}
{$IFDEF CPPB_6}          {$DEFINE SYN_CPPB_6}          {$ENDIF}
{$IFDEF CPPB_6_UP}       {$DEFINE SYN_CPPB_6_UP}       {$ENDIF}

{$IFDEF DELPHI}          {$DEFINE SYN_DELPHI}          {$ENDIF}

{$IFDEF DELPHI_2}        {$DEFINE SYN_DELPHI_2}        {$ENDIF}
{$IFDEF DELPHI_2_UP}     {$DEFINE SYN_DELPHI_2_UP}     {$ENDIF}
{$IFDEF DELPHI_3}        {$DEFINE SYN_DELPHI_3}        {$ENDIF}
{$IFDEF DELPHI_3_UP}     {$DEFINE SYN_DELPHI_3_UP}     {$ENDIF}
{$IFDEF DELPHI_4}        {$DEFINE SYN_DELPHI_4}        {$ENDIF}
{$IFDEF DELPHI_4_UP}     {$DEFINE SYN_DELPHI_4_UP}     {$ENDIF}
{$IFDEF DELPHI_5}        {$DEFINE SYN_DELPHI_5}        {$ENDIF}

Wenn ich einige über diesem Block stehenden Kommentarzeilen entferne, ändert sich die Fehlermeldung. Es wird immer Zeile 512 angemeckert. Sieht nach irgendeinem Buffer-Limit o.ä. aus. Hmm..

Zitat:

... ändert sich die Fehlermeldung

soll heißen: Es ist immer noch "INTERFACE expected ..." aber dann z.B. mit "... but number found."

Das komische dabei ist, daß die SynEditMiscProcs.pas nicht die erste zu kompilierende Unit ist. Die 2 vorangehenden Units können kompiliert werden, enthalten aber genau die gleichen Direktiven an der gleichen Stelle: zwischen UNIT bla; und Interface

Das Problem ist wohl schon mal bei Borland gemeldet worden:
http://qc.borland.com/wc/qcmain.aspx?d=44731

Workaround: Benutze den -Q Schalter. Obwohl das eigentlich nur "Quiet compile" bedeutet - eigentlich was anderes als "Fehler ignorieren" o.ä. ...

Jedenfalls kompiliert es so mit dcc32.exe . Ich bekomme zwar leider keinen Output mehr und weiß dementsprechende nicht was er gerade macht, aber die DCUs werden jetzt erzeugt und eine Fehlermeldung gibt es auch nicht (Ich hoffe mal nicht daß der Compiler die wegen des Q-Schalters auch unterdrückt...).

Zitat von anse:

Das Problem ist wohl schon mal bei Borland gemeldet worden:
http://qc.borland.com/wc/qcmain.aspx?d=44731

Ich hoffe es ist nicht das was ich jetzt denke. Als ich den JVCL Installer schrieb fiel mir ein Bufferoverflow im Dcc32.exe auf. Wenn der Pfad zu lange wurde war der Compiler eine Schutzverletzung. Der Workaround war: Keine Warnungen, Hinweise und Fehler im Quellcode zu haben und mit -Q zu kompilieren.
Mit Delphi 2005 wurde dieses Problem dann endlich behoben. Aber wenn das nun das selbe Problem ist, dann überschreibt der Compiler nun bei der Ausgabe nicht mehr "wichtige" Daten die für die Ausführung benötigt werden, sondern den Parser-Baum.

Ich denke schon das es genau der gleiche Bug ist. Der Poster des Bugs schreibt auch u.a.:

Zitat von dynamic hearing:

Fatal: F2084 Internal Error: D21153

This happens with code that compiled OK with dcc32.exe from Delphi 2005.

Wäre nicht der erste Bug der Welt, der "re-introduced" worden wäre.

Zitat von anse:

Wäre nicht der erste Bug der Welt, der "re-introduced" worden wäre.

Der Bug war im RTM von Delphi 2007. Wurde aber durch das Update 1 behoben.