Ich hab den Fehler nicht. Allerdings war mir dieselbe Stelle auch gestern schon untergekommen, als ich Laz 1.8.4 mit FPC-Trunk übersetzen wollte. Bist du sicher, dass du Laz-Trunk compilierst? Die fragliche Stelle in win32winapi.inc enhält bei Trunk {$IF fpc_fullversion < 30101}, bei Laz 1.8.4 dagegen nicht.
wp_xyz hat geschrieben:Ich hab den Fehler nicht. Allerdings war mir dieselbe Stelle auch gestern schon untergekommen, als ich Laz 1.8.4 mit FPC-Trunk übersetzen wollte. Bist du sicher, dass du Laz-Trunk compilierst?
Ja, da ist es mir wieder gelungen, mich selbst zu überlisten. Um Lazarus Trunk nicht komplett neu konfigurieren zu müssen (Docking etc.) habe ich das komplette Lazarus Konfigurationsverzeichnis kopiert und die Kopie als Konfigurationsverzeichnis für Trunk hergenommen. Aber anscheinend stehen da irgendwo absolute Pfade, sodass er einiges nicht aus dem LazTrunc-Verzeichnis holt, aus dem heraus ich Lazarus starte, sondern aus dem alten Lazarus Verzeichnis. D.h. ich kann mir das nicht sparen und muss mit einem komplett neuen Konfigurationsverzeichnis starten. Mal sehen, ob damit der andere Fehler dann auch verschwindet.
Ich habe geschaut, aber es auf die Schnelle nicht gefunden - weisst du vielleicht, in welcher Datei das AnchordockingDsgn seine Konfiguration ablegt? Zumindest die würde ich gerne rüberkopieren, weil das wieder so hinzubekommen, wie ich es haben will, ist eine ziemliche Spielerei.
braunbär hat geschrieben:Ich habe geschaut, aber es auf die Schnelle nicht gefunden - weisst du vielleicht, in welcher Datei das AnchordockingDsgn seine Konfiguration ablegt?
Möglicherweise ist es in environmentoptions.xml, Node "Desktops" - da sehe ich bei meiner gedockten IDE zwei Einträge mit Namen "default" und "docked default". Weil in der Datei einige absolute Pfade stehen, ist es vielleicht am einfachsten, den ganzen Node "Desktops" der einen durch den der anderen Datei zu ersetzen. Aber mache vorher eine Backup-Kopie der Datei.
Jetzt nochmal neu gestartet FPC trunk und lazarus Trunk noch einmal sauber installiert, und dann das Lazarus.exe 1.8.4 ins LazTrunc Verzeichnis kopiert.
Wenn ich jetzt mein Projekt (nur ein ganz simples Rahmenprogram zum Testen der Stringlisten) komplett neu kompilieren wil, findet er immer wieder INC Dateien vom FPC Laufzeitsystem nicht. Erst war es ein inc File aus dem Verzeichnis c:\FPC\Trunc\rtl\inc\, das Verzeichnis habe ich zu den Include-Verzeichnissen des Projekts hinzugefügt, aber jetzt findet er wieder sysosh.inc nicht. Irgend etwas ist daa falsch, es kann ja nicht sein, dass ich bei jedem Projekt eine Unmenge FPC-Runtime-Dateien zum Suchpfad hinzufügen muss.
Kurioserweise konnte ich den Lazarus Trunk sebst problemlos kompiieren (und arbeite jetzt an diesem Projekt sogar mit Laz Trunk 2.1.0 weiter), nur bei meinem kleinen Testprojekt stellt es ihn auf.
Tritt das bei jedem Projekt auf, oder nur bei dem Test-Projekt, bei dem du, wie ich ganz oben empfohlen habe, die Unit classes dem Projekt hinzugefügt hast? In letzterem Fall wäre das zu erwarten, denn es werden alle Units neu übersetzt, die von dem Projekt benötigt werden, und dazu müssen auch alle inc-Dateien gefunden werden.
Übrigens, falls du einen Patch zur Classes-Unit einreichen möchtest,solltest du das Testprojekt möglichst einfach halten, möglichst nur ein Konsolen-Projekt. Die FPC-Entwickler tun sich leichter, wenn bei Patches nur das nötigste benötigt ist.
Und bei einem Konsolen-Testprogramm für TStringList, denke ich, sind auch nicht viele inc-Datei einzubinden.
Das klingt sehr plausibel. Nachdem er beim Übersetzen des kompletten Lazarus Codes keine Beschwerden hatte, wird es sicher daran liegen. Die Dateistrutur der FPC Sourcen ist schon mühsam, aber das ist bei einem soclchen MultiPlattform Code wahrscheinlich schwer zu vermeiden. Ich habe mir gestern gedacht, dass da in meiner Installation ein gröberes Problem ist (vor allem, weil auch die Dateistruktur vom FPC Trunk anders ist als die vom FPC, der als Teil von Lazarus installiert worden ist), aber das ist dann anscheinend doch nicht der Fall. Na gut, kommen halt in das Projekt ein paar Inc-Pfade dazu, irgendwann werde ich ja hoffentlich alle hinzugefügt haben, die ich brauche.
Was ich allerdings nicht verstehe, ist, warum er beim Kompilieren des FPC-Projekts selbst diese inc-Dateien findet. Da sind bei auch keine Unmengen Suchpfade eingetragen.
edit Eigentlich mag ich Konsolenprojekte überhaupt nicht - ich hätte es lieber mit einem GUI Projekt getestet. Zum Projekt hinzufügen müsste ich die Unit Classes ja nur, während ich entwickle, und wenns fertig ist, könnte ich sie ja wieder aus dem Projektpfad entfernen. Die FPC Units werden zwar neu übersetzt, aber Änderungen gibt es voraussichtich nur in ganz wenigen Dateien. Das würde ja eigentlich nicht komplizierter, wenn das Testprojekt ein kleines GUI Projekt wäre. Leider macht das aber beim Übersetzen Schwierigkeiten ohne Ende, es sind nicht nur inc-Files, die er nicht findet, jetzt hat er eben eine undeklarierte Variable reklamiert... Ich werde mich also doch auf ein ganz einfaches Kommandozeilenprogramm beschränken, wie du es empfohlen hast. Das übersetzt er wenigstens ohne zu maulen.
Ich habe das gerade getestet, ja, das ist sehr lästig und es gibt noch weitere Fallstricke, wobei ich Michl um Hilfe bitten musste (Danke nochmals!), nämlich den Default-Assembler-Mode festlegen (-Ratt als Benutzeroption) und die Mischung von Short- und AnisStrings vermeiden ({$H+} in Projektoptionen entfernen und im Header der Projektdatei löschen).
Vor kurzem hatte ich das Vorgehen mit irgendeiner Datenbank-Datei durchgespielt, also FCL, nicht RTL, und da war das wesentlich leichter anzustellen.
Ich vermute dass diese Einstellungen beim Compilieren des FPC in der make-Datei eingetragen sind - nur muss ich zu meiner Schande gestehen, dass ich die make-Datei noch nie verstanden habe...
Das beigefügte Trivialprogramm mit einer StringList compiliert und läuft nun einwandfrei, und v.a. ich kann mit "F7" problemlos mit dem Debugger den Code der StringList durchsteppen. Leider stehen in der lpi-Datei die absoluten Pfade für mein System. Du müsstest die lpi-Datei mit einem Editor öffnen und alle "c:\development\fpc\trunk" durch den Pfad zu den Dateien deiner FPC-Trunk-Installation ersetzen.
braunbär hat geschrieben: Das übersetzt er wenigstens ohne zu maulen.
Hab ich geglaubt. Keine Rede davon.
Vielen Dank für deine Unterstützung, ohne die hätte ich spätestens an der Stelle aufgegeben. Mit einer lauffähigen Vorlage sollte es jetzt bei mir aber auch funktionieren.
wp_xyz hat geschrieben:Ich vermute dass diese Einstellungen beim Compilieren des FPC in der make-Datei eingetragen sind
Ja, das wird wohl so sein - aber zum Debuggen müssten die Code-Tools doch auch die Incude-Files finden, dafür gibt es kein make. Naja, wie auch immer...
Leider gibt es immer noch Probleme, ich habe den 64Bit FPC, den entsprechenden Suchpfad c:\FPC\Trunc\rtl\x86_64\ habe ich noch dem Projekt hinzugefügt. Aber jetzt bekomme ich einen Compilerfehler - in Threadmain. Mir ist aufgefallen, dass momentan im Bereich Threads intensiv gearbeitet wird. Es kann sein, dass irgend etwas mit den Suchpfaden und den defines bei mir noch immer nicht stimmt, aber es ist auch möglich, dass der Trunk-Snapshot, den ich habe, nicht ganz hinhaut. Werde morgen beide Trunks, Lazarus und FPC, aktualisieren.
Edit: Ich habe jetzt noch ein bißchen herumprobiert, ich fürchte, die Projekteinstelungen passen irgendwo nicht zu meinem 64-Bit Lazarus / FPC. Morgen installiere ich mir eine 32-Bit Version, für die Aufgabe ist es ja völlig egal.
Links
