Erfahrungen mit RS 10.3(.1) und bcc32c?
-
Ich versuche gerade unser Projekt vom RS 10.2 auf 10.3 umzustellen (nachdem wir alle boost-Referenzen entfernt haben). Derzeit läuft RS 10.3.1 dabei in einer VM und ich wollte fragen ob andere ähnlich schlechte Erfahrungen gemacht haben (kann zum Teil an der VM liegen, aber eine andere VM mit RS 10.1, die ich für eine alte Projektversion habe, hat die Probleme nicht oder nicht in dem Maßen):
- Häufiges Hängen der IDE (selbst mit Abgeschalteter Codevervollständigung etc. - mit haben wir noch nie vernümpftig arbeiten können).
- Extrem lange Compilezeiten
- Extrem träges Verhalten der IDE (dagegen waren selbst 10.1 und 10.2 pfeilschnell)
- Sehr merkwürdige Fehler im Zusammenhang mit großen Projekten (nachdem ich ca. 50h damit verbracht habe, unser Hauptprojekt in eine weitere statische lib und eine überwiegend auf Form-Dateien beschränkte exe zu splitten, treten diese nicht mehr auf): beim Compilieren werden Slash/Backslash von Pfadangaben geschluckt oder der Punkt von obj-Dateien in Backslashes gewandelt (so dass das compilieren/linken scheitert).
-
@asc
Ich hatte es direkt nach der Installation nicht geschafft, eine leere Formular- Anwendung in 32 Bit mit clang übersetzt zu bekommen aufgrund genau des Fehlers, das der Punkt von obj Dateien in Backslash umgewandelt wurde.
Ich habe diesen schweren Fehler auch gleich an den Support gemeldet:https://quality.embarcadero.com/browse/RSP-23098
Der Vorgang steht auf erledigt, aber so wie du hier berichtest, ist er wohl doch nicht (ganz) weg, von daher mach doch nochmal einen neuen entsprechenden Vorgang auf.
Da ich TwineCompile benutze, habe ich dieses Problem nicht (mehr).
Und solange boost nicht erhältlich ist, arbeite ich zunächst erstmal mit 10.2.3 weiter. Die Codevervollständigung benutzte ich auch nicht, weil eben die IDE zu lange "hängt" (und bei 10.2.3 auch öfters mal zu einer Exception führt. Das ist noch schlimmer in einen zweiten Editorfenster, da führt das meist dann dazu, das die IDE abgeschossen werden muss).
Lange Compilierzeiten habe ich auch mit Visual Studio 2017, zumindest bei C++. Da nehmen sich beide nichts, so zumindest meine Erfahrung.
-
Nachtrag: Ein Teil der compilierzeit liegt daran, das die IDE immer mal wieder die pch wegschmeißt... Es reicht meist nicht, das man die Datei mit "Use for Precompilation" markiert (fliegt auch gerne raus), diw folgende Zeile muss händisch ebenso der Projektdatei zugefügt werden (Zumindest im RS10.2, im RS10.3 werde ich das im nächsten Lauf probieren)!
<BCC_PCHName_Clang>pch.h</BCC_PCHName_Clang>
-
@Burkhi sagte in Erfahrungen mit RS 10.3(.1) und bcc32c?:
Da ich TwineCompile benutze, habe ich dieses Problem nicht (mehr).
Mal eine Gegenfrage: Warum nutzt ihr mit dem clang noch TwineCompile? Haben den seit der clang-Umstellung abgeschafft, ich habe eben Testweise mal die aktuelle 30-Tage-Version unter der RS10.3-VM installiert. Das bauern dauert fast exakt (in meinen Fall sogar ca.5% länger) als wenn ich Batch-Build mit der entsprechenden Prozessoranzahl aktiviere (In den "Project Options" die folgenden Einstellungen ändern: "C++ Compiler, General Compilation, Enable batch compile" und "Project Properties, General, Run C++ compiler in a separate process" zusammen mit "Number of subprocesses" = Anzahl Threads des PCs).
-
@asc
Danke für den hinweis mit der zusätzlichen Zeile in der Projektdatei.
Ich hatte mir twine compile mal für XE7 gekauft, weil es dort nicht möglich war, mein Programm mit dem internen Compiler zu übersetzen, es gab immer "Not enough Savemem".
Das der Batch Build inzwischen genauso schnell ist, habe ich auch schon gemerkt, jedoch konnte ich ja auch alle Updates von twine compile "mitnehmen" und ich finde es ganz gut, das schon direkt beim speichern die Datei kompiliert wird, so werden halt Tippfehler etc. gleich angezeigt.
