BDS2006 Delphi Debug funktioniert nicht?

[Terminar]

Hallo Allerseits,

ich bin ziemlich frustriert und verzweifelt. Nachdem ich zwangsweise auf BDS2006 umsteigen musste, funktioniert das debuggen bei Delphi-Source nicht mehr in C++ Projekten (die PAS-Dateien im Projekt eingebunden haben). Wenn ich ein reines Delphi-Projekt erstelle funktioniert es weiterhin.

Das Debuggen in den cpp-Dateien funktioniert, sobald ich aber einen Breakpoint in Delphi-Source setze und das Projekt starte ignoriert er die Breakpoints (wenn ich mich recht entsinne macht er sogar das (x) ) in Rot als Breakpoint als wenn ihm irgend etwas fehlen würde.

Kann damit jemand was anfangen? Das Arbeiten ist so ziemlich schwierig :(

Bis denn
Björn

[DMW]

Zitat:

Zitat von Terminar

Nachdem ich zwangsweise auf BDS2006 umsteigen musste

(Nur aus Interesse) Von wo kommst du? C++Builder 6?


Möglicherweise sind in den Optionen die Debug-Informationen für Delphi-Units deaktiviert. Bei mir funktioniert das in Turbo Delphi/C++ (mittels Andreas' TEMerger zusammengeführt) ganz einwandfrei.

[RavenIV]

/offtopic
Im BDS kann man Delphi-Units und C++-Units mischen?
Und der compiliert das dann zusammen zu einer exe?

Wenn das wirklich gut hinhaut, dann werde ich das auch mal testen...

[Muetze1]

@RavenIV: Klar geht das. Schon immer so gewesen beim C++Builder, der konnte schon immer Delphi Quellen compiliere, debuggen etc. Schon allein die VCL des C++Builders sind genau die gleichen Quellen wie im Delphi. Die RAD/BDS Dinger verbinden nun nur Delphi und den C++Builder in ein Produkt.

@Terminar: Also wir haben hier keine solche Probleme, aber afair gibt es das Problem, dass der Debug-DCU Pfad nicht ordentlich bei dir angegeben ist. Die Debug BPL/BPI und Libs müssen angegeben werden, also der Suchpfad angepasst werden. Hast du die Einstellungen schonmal kontrolliert bei dir?

[Terminar]

Zitat:

Zitat von Muetze1

@RavenIV: Klar geht das. Schon immer so gewesen beim C++Builder, der konnte schon immer Delphi Quellen compiliere, debuggen etc. Schon allein die VCL des C++Builders sind genau die gleichen Quellen wie im Delphi. Die RAD/BDS Dinger verbinden nun nur Delphi und den C++Builder in ein Produkt.

Jopp, was auch meiner Meinung nach wirklich eine geniale Sache ist.

Zitat:

Zitat von Muetze1

@Terminar: Also wir haben hier keine solche Probleme, aber afair gibt es das Problem, dass der Debug-DCU Pfad nicht ordentlich bei dir angegeben ist. Die Debug BPL/BPI und Libs müssen angegeben werden, also der Suchpfad angepasst werden. Hast du die Einstellungen schonmal kontrolliert bei dir?

Beim BCB6 hatte ich auch mal so ein Problem, da war es der Debug-Pfad. Ich werde mir mal jetzt den Abend versauen und komplett alle Einstellungen nochmals von Grund auf durchtesten... Irgendwie kann das ja nicht sein das das nicht mehr geht.

Kann mir jemand einen Gefallen tun und ein kleines BDS2006 Projekt erstellen, einfach nur ein Formular mit nem Button und einer .pas-Datei mit irgendeiner kleinen Funktion die beim Button-Klick aufgerufen wird und die man mit Breakpoint debuggen kann? Wäre super. Vielleicht hat jemand auch irgendwo seine Default-BDS Config, liegt ja irgendwo im \bin Ordner rum. Ich würde gerne mal die Configs diffen und schauen wo bei mir der Unterschied ist...

Ich glaube irgendwas ist bei mir zerschossen, wobei das bei einem Kollegen von mir auch ist :(

Bis denn
Björn

[DMW]

Zitat:

Zitat von Terminar

Kann mir jemand einen Gefallen tun und ein kleines BDS2006 Projekt erstellen, einfach nur ein Formular mit nem Button und einer .pas-Datei mit irgendeiner kleinen Funktion die beim Button-Klick aufgerufen wird und die man mit Breakpoint debuggen kann? Wäre super. Vielleicht hat jemand auch irgendwo seine Default-BDS Config, liegt ja irgendwo im \bin Ordner rum. Ich würde gerne mal die Configs diffen und schauen wo bei mir der Unterschied ist...

Im Anhang.

Eine Default-Konfigurationsdatei konnte ich aber nicht finden; sie scheint nicht mehr dort zu sein, wo sie bei C++Builder 6 noch war.

[Terminar]

Hi DMW,

sorry, auf dein Post wollte ich noch vorhin antworten. Ja, angefangen irgendwann mal vor Ewigkeiten mit Turbo Pascal 5-7, dann in Richtung C/C++ geschwenkt und durch meinen damaligen neuen Job das erste mal mit dem BCB5 gearbeitet und war recht angetan, weil ich mir vorher VS6 antun musste... Mit dem ersten Delphi unter Windows bin ich damals irgendwie nicht klar gekommen, war nicht mein Ding, von daher bin ich von Pascal weg. Zählt auch nicht mehr wirklich zu meiner Lieblings-Sprache :) Naja, irgendwann dann BCB6 und jetzt das BDS2006...

Zitat:

Zitat von DMW

Im Anhang.
Eine Default-Konfigurationsdatei konnte ich aber nicht finden; sie scheint nicht mehr dort zu sein, wo sie bei C++Builder 6 noch war.

Vielen Dank! Zumindest weiss ich jetzt, das es nicht am reinen Projekt liegen kann, weil ich damit auch den Delphi Code nicht debuggen kann. Kommt sofort bei Programmstart im Debug das (x) in rot und die Codezeile grün. War normalerweise beim BCB immer ein Zeichen dafür, neenee, nix debug...

Btw, die Default-Config liegt jetzt bei mir mit Vista unter C:\Users\<UserName>\AppData\Local\Borland\BDS\4.0\ DefProject.bdsproj und müsste warscheinlich unter XP auch irgendwo unter C:\Dokumente und Einstellungen\<UserName>\*\Borland\BDS\4.0\DefProj ect.bdsproj liegen...

Ich werde mal alle zusätzlichen Erweiterungen deaktivieren oder deinstallieren, in der Hoffnung, das das etwas bringt.

Danke nochmals an Alle die bisher so rege Feedback gegeben haben.

[Terminar]

Gut. Jetzt bin ich restlos verwirrt. Borland möchte eigentlich wohl nur dafür sorgen, das ich einen weißen Kittel mit langen Ärmeln anziehe.
Ich habe jetzt alles ausprobiert, erstmal meine Erweiterungen deinstalliert, nochmal die Standard-Optionen überprüft...

Auf meinem Arbeitsrechner ging es dann auf einmal. Dann dachte ich ok, das ganze jetzt nochmal Stück für Stück ausprobieren an einer Installation wo noch die ganzen Erweiterungen installiert sind. Kein Problem, sobald 2 Optionen beim Linker gesetzt waren: Map-Datei detailiert erstellen und detailierte Linkerinformationen (sinngemäß irgendwas in der Art, die VM ist schon runtergefahren) konnte ich debuggen.

So, nun ging ich davon aus, falls ich die Optionen wieder deaktiviere kommt der Fehler wieder. Der Witz dabei ist nun aber: es geht trotzdem! Einmal diese Optionen verändert und ich kann wieder debuggen, egal ob nun aktiviert oder deaktiviert. Ich hatte auch die Testprojekte nochmal neu entpackt, objects und mapfile gelöscht etc, völlig egal... Es geht...

Ich werde das morgen mal mit den 2 Optionen bei einem Kollegen probieren, zuerst die eine, wenns dann noch nicht geht die Andere. Im Bestfall habe ich das Problem zumindest eingrenzen können. Es wäre nur schön, wenn es reproduzierbar wieder "deaktivierbar" wäre, damit ich genau weiss, ok, DAS ist das Problem gewesen :( Nunja, ich schaue morgen, ich halte euch auf dem laufenden.

Bis denn
Björn

[Terminar]

Hallo Allerseits,

ich denke, ich habe den Grund gefunden, fast schon etwas peinlich.
Ich nutze den TwineCompile um etwas Geschwindigkeit in's Compilen zu bekommen. Bisher war der auch immer recht zuverlässig (kann ich btw wirklich nur empfehlen).
Ich war auch der Meinung, daß ich den beim Testen deaktiviert hatte, um ihn als Grund auszuschließen. Tja, scheinbar aber nicht. Heute morgen beim Rechner vom Kollegen konnte ich allerdings sehr genau den TwineCompile als Fehlerquelle ausmachen. Mittlerweile gibt es eine neuere Version von dem Ding und ich hab's mal dem Entwickler gemeldet.

Danke nochmal für die Hilfe. Ich bin begeistert, wie schnell und konstruktiv hier Hilfe kam, es gibt tatsächlich noch hilfreiche Foren :)

Bis denn
Björn

[RavenIV]

Was ist der TwineCompile?
Hast Du da einen Link dazu?

[mkinzler]

http://www.jomitech.com/twine.php

[Terminar]

Zitat:

Zitat von RavenIV

Was ist der TwineCompile?
Hast Du da einen Link dazu?

Der TwineCompile ist eine Erweiterung für die Borland-IDE's, um die Geschwindigkeit beim compilen erheblich zu erhöhen.

Einerseits mehrere Threads parallel zum compilen, andererseits glaube ich paar Optimierungen, bin ich aber gerade nicht sicher. Fazit ist, bei einem Projekt von uns brauchte der BCB6 anstatt 20 Minuten nur noch 2 Minuten zum compilen.
Gibt noch ein ähnliches Programm, nennt sich BuilderBooster und wird glaube ich auch als Personal-Edition mitgeliefert beim BDS auf der ZusatzCD, hatte ich aber Ärger mit, der Twine ist auch günstiger, ich find's preislich fair und für uns war das absolut sinnvoll.

Den TwineCompile gibt es unter http://www.jomitech.com/twine.php mit Demo-Version etc. Der Entwickler reagiert immer schnell, nimmt Wünsche auf und setzt sie auch (zumindest meine hatte er recht zeitnah eingebaut).

Für die ganz Harten gibt es noch den LanCompiler, auch ne nette Idee. Hier können einzelne Rechner im Lan zum compilen genutzt werden. Das ganze lässt sich dann auch untereinander nutzen und ist auch recht praktisch, ich hatte da mal am Betatest teilgenommen. Allerdings sehe ich da gerade noch keine Download-Möglichkeit als Trial, ich frag den Entwickler mal...

Bis denn
Björn

[stahli]

Zitat:

Zitat von Terminar

Fazit ist, bei einem Projekt von uns brauchte der BCB6 anstatt 20 Minuten nur noch 2 Minuten zum compilen.

Oups, was ist das denn für ein Projekt? Ich habe bisher nur relativ übersichtliche Projekte entwickelt, allderdings auch mit eigenen Komponenten und Packages. Mehr als 10-20 Sekunden musste ich nie warten...

20 Minuten kann ich mir kaum vorstellen. Geht das anderen auch so?

stahli

[RavenIV]

Zitat:

Zitat von stahli

Zitat:

Zitat von Terminar

Fazit ist, bei einem Projekt von uns brauchte der BCB6 anstatt 20 Minuten nur noch 2 Minuten zum compilen.

Oups, was ist das denn für ein Projekt? Ich habe bisher nur relativ übersichtliche Projekte entwickelt, allderdings auch mit eigenen Komponenten und Packages. Mehr als 10-20 Sekunden musste ich nie warten...

20 Minuten kann ich mir kaum vorstellen. Geht das anderen auch so?

stahli

Das ist keine so abwegige Zeit für einen kompletten Projekt-Build.
Bei dem Projekt bei meinem ehemaligen Arbeitgeber dauerte ein Build auch meistens knapp 15 Minuten.
Und es wurde extra schon der Komandozeilen-Compiler eingesetzt, weil die IDE noch langsamer war.
Es war ein D7-Projekt mit 5 exe-Files und ca. 15 dll's.
Die mussten immer alle gemeinsam kompiliert werden, damit die Abhängigkeiten wieder stimmten.

[Terminar]

Zitat:

Zitat von stahli

20 Minuten kann ich mir kaum vorstellen. Geht das anderen auch so?

stahli

Naja das geht schon. Ich war auch damals massiv überrascht als das Projekt gewachsen ist und die Zeit zum kompletten Erstellen so erheblich zugenommen hat. Zwischendurch hatten wir noch ein Problem mit dem BCB6, daß er in einem Source der Meinung war, bei der kleinsten Veränderung das komplette Projekt neu erstellen zu wollen. Das war ziemlich unangenehm... Nach optimieren der PCH's ging es dann einigermaßen, war aber im groben und ganzen trotzdem nicht so das Optimale.

Zitat:

Zitat von RavenIV

Bei dem Projekt bei meinem ehemaligen Arbeitgeber dauerte ein Build auch meistens knapp 15 Minuten.
Und es wurde extra schon der Komandozeilen-Compiler eingesetzt, weil die IDE noch langsamer war.
Es war ein D7-Projekt mit 5 exe-Files und ca. 15 dll's.
Die mussten immer alle gemeinsam kompiliert werden, damit die Abhängigkeiten wieder stimmten.

Jopp, das deckt sich ungefähr mit unserem Projekt. Seit dem Twine hat sich das allerdings normalisiert. Dazu noch das http://andy.jgknet.de/dspeedup/ das ja glaube ich auch hier von einem Entwickler aus dem Forum war (?) und ich bin zufrieden.

Als der BDS2006 auf den Markt kam war ich ziemlich enttäuscht, das Borland immernoch nicht Multithread-Compile für sinnvoll erachtet... Aber nerjo, da freuen sich dann wenigstens ein paar Tools-Entwickler.

Bis denn
Björn

[Muetze1]

Zitat:

Zitat von stahli

Oups, was ist das denn für ein Projekt? Ich habe bisher nur relativ übersichtliche Projekte entwickelt, allderdings auch mit eigenen Komponenten und Packages. Mehr als 10-20 Sekunden musste ich nie warten...

Dann scheinst du dem pre-compiled Headern zu vertrauen. Leider bauen die öfters mal Müll, weswegen sie dem C++ Builder 5 nicht mehr nutzbar waren.

[RavenIV]

Zitat:

Zitat von stahli

Oups, was ist das denn für ein Projekt? Ich habe bisher nur relativ übersichtliche Projekte entwickelt, allderdings auch mit eigenen Komponenten und Packages. Mehr als 10-20 Sekunden musste ich nie warten...

Hast Du eigentlich schon mal versucht, einen kompletten Build (also nicht Kompilieren, sondern Erzeugen) zu machen?
Wenn das bei Dir auch nur ein paar Sekunden dauert, dann hast Du wohl nur Mini-Projekte.

[stahli]

@ Muetze1 + RavenIV:

Jetzt habe ich Euch vielleicht verwirrt...!?
Ich habe immer nur DelphiPascal für Win32 programmiert, kleine bis mittlere Projekte (D1 - D2006).

Mein aktuelles Projekt hat mehrere Formulare und eigene Komponenten in eigenen Packages. Alles neu zu erzeugen dauert ein paar Sekunden.
Für ein "riesiges Riesen-Projekt" hätte ich vielleicht mit 2-3 Minuten gerechnet.

Kann mir nicht wirklich vorstellen, dass es bei C-Code so viel länger dauern soll...

-alles irgendwie komisch ;-)

stahli

[Muetze1]

Mit anderen Worten: du nennst Zeiten für Pascal Projekte und vergleichst diese "Eier" mit Birnen?

Der C(++) Compiler ist ein Multi-Pass Compiler wobei es (bei manchen) vorher noch einen Preprocessor Compile gibt. Ein C++ Compiler kommt grundlegend auch durch die viel umfangreicheren sprachlichen Möglichkeiten nicht an die Compile-Zeiten vom Delphi Compiler heran. Wenn ich hier mal so unsere C++ Anwendungen erstelle (wenn ich Zeit habe in der IDE und nicht per CmdLine), dann kann man sich schon mal locker einen Kaffee holen. Hängt aber ganz von der Projektgröße ab.

Grundlegend: Du kannst nicht Compiler mit Compiler sprachübergreifend vergleichen.

[RavenIV]

Also das Projekt damals war in fast 30 Teilprojekte aufgeteilt.
Jedes dieser Teilprojekte hatte circa 4-5 Fenster und weitere Units ohne Fenster.
Der gesamte Quellcode muss über 100'000 (ein-hundert-tausend) Zeilen lang gewesen sein.
Das zumindestens hat so ein externes Tool behauptet, den Angaben vom Delphi kann man ja nicht glauben.

So nun fangen wir an zu rechnen:
Wir haben 30 Teilprojekte.
Jedes Teilprojekt braucht "nur" 30 Sekunden.
Sind schon mal 15 Minuten vergangen.
Dann rechnet man noch die Zeit dazu, die der Compiler und Linker verplämpert, bis er erst wieder mit dem nächsten Teilprojekt weitermacht (Dateien laden, Konfiguration lesen, usw.).
Dann sind wir bei 20 Minuten.

Oder hab ich mich da verrechnet?

[stahli]

Na dann nehmt doch Pascal! :zwinker:
Ich dachte, das wäre quasi das gleiche, nur dass man alles irgendwie verquer schreiben muss :gruebel:

Sorry für die Verwirrung, aber ich hab dadurch zumindest etwas dazugelernt...

Gruß Stahli

[DMW]

Eine weitere Strategie zum Kleinhalten der Build-Zeiten wäre, notwendige Veränderungen am Modulinterface nicht immer bei Bedarf anzubringen, sondern zu sammeln und erst am Ende der Arbeitseinheit zu implementieren, so daß bis dahin die einzelnen Module ohne einen kompletten Rebuild weiterentwickelt werden können.

Ein guter Architekt trägt dementsprechend wesentlich zur Verringerung der Build-Zeiten bei ;)

[Terminar]

Zitat:

Zitat von DMW

Ein guter Architekt trägt dementsprechend wesentlich zur Verringerung der Build-Zeiten bei ;)

Jupp, geht auch wenn er allein arbeitet, aber viele Köche verderben bekanntlich den Brei :)

Bis denn
Björn
;)