D2009 - Wie Generics.*.pas neu kompilieren?

[Daniel]

Moin,

nachdem ich festgestellt habe, dass einige der Enumeratoren bei den generischen Containern bei D2009 defekt sind, habe ich die Quelldateien per Hand gepatcht - das war nicht so wahnsinnig schwierig.

Doch wie kompiliere ich diese Dateien neu? Mein erster Versuch über die Kommandozeile brachte mir zwar DCUs, die stimmen in der Größe jedoch nicht mal im Groben mit den vorherigen Dateien überein und knallen mir auch an Stellen weg, an denen ich nichts geändert habe.

Nun habe ich diverse Compilerschalter probiert, darunter auch Bereichsprüfung und Überlaufprüfung an- und ausgeschaltet - leider ohne Erfolg.

Kann mir wer einen Tipp geben, wie man Teile der VCL neu übersetzt?

[DeddyH]

Auch wenn ich noch nie die Originaldateien gepatcht habe... müsste man das enthaltende Package nicht neu kompilieren? Diese Angaben sind wie immer ohne Gewähr :mrgreen:

[Bernhard Geyer]

Zitat:

Zitat von Daniel

Kann mir wer einen Tipp geben, wie man Teile der VCL neu übersetzt?

Geht doch gar nicht, jedenfalls nicht für die Packages von Codegear. :gruebel:

Wenn du ohne Packages arbeitet könntest du die angepaßte Datei in dein Projektverzeichnis kopieren (oder eine VCL-Patch-Verzeichnis im Suchpfad aufnehmen). Willst du Packages mußt du dir deine eigene Packagesammlung ähnlich der Standardsammlung zusammenstellen.

[Luckie]

Zitat:

Zitat von Daniel

nachdem ich festgestellt habe, dass einige der Enumeratoren bei den generischen Containern bei D2009 defekt sind, habe ich die Quelldateien per Hand gepatcht - das war nicht so wahnsinnig schwierig.

Du machst auch alles kaputt. Wenn man dir mal was in die Hand gibt. :mrgreen:

Sorry, ich konnte nicht widerstehen. :oops:

[Daniel]

Moin,

auf die Packages hätte ich verzichten können.

Meine Brachial-Lösung sah so aus, dass ich die beiden .PAS Dateien in mein Projektverzeichnis kopiert und sie auch explizit ins Projekt eingebunden habe. Die geänderten Dateien sind dann auch im Rahmen meiner EXE verwurstet worden. Aber leider flogen dann eben Hashing-Funktionen und Key-Collections weg - da bin ich dann ausgestiegen, da ich auch mit und ohne Bereichs- und Überlaufprüfung keinen Erfolg verzeichnen konnte.

Konkret geht es darum, dass man beim TDictionary nicht über die Keys iterieren kann, da der Iterator einen Schritt zu weit geht und am Ende einen ungültigen Eintrag zurückliefert. Im Quellcode ist das rasch korrigiert, doch gelingt es mir eben nicht, die Änderungen zu übersetzen. Der Fehler ist bereits in der Quality-Central von CG und wird hoffentlich auch bald korrigiert. Zwischenzeitlich zähle ich selbst die Einträge mit und steige rechtzeitig aus. Hübsch ist es nicht - aber es geht.

@Michael: Das merke ich mir. :mecker: :mrgreen:

[Chemiker]

Hallo Daniel,

vielleicht kann Dir Andreas (jbg) weiter helfen.

Bis bald Chemiker

[jbg]

Zitat:

Zitat von Chemiker

vielleicht kann Dir Andreas (jbg) weiter helfen.

Und wie kommst du da drauf? Ein Neukompilieren von Generics kann nur in einem Caos enden, da diese ja nicht in die Generics.*.dcu kompiliert, sondern dort per Quellcode reingeschrieben werden. Nutz eine andere Unit die Generics dann kommt die aktuell gültige "Implementierung" in die Zielunit. Ändert man im nachhinein die Generics, dann interessiert das die bereits falsch kompilierte Unit einen Fliegendreck. Mehr kann ich dazu aber auch nicht sagen, außer, dass sich Berry Kelly da was einfallen lassen muss damit das funktioniert, weil Generics.*.pas ist im Moment unbrauchbar.

[Dezipaitor]

Was ich nicht verstehe, wie können die von Emb. die Unit kompilieren?

[jbg]

Vielleicht haben sie den -z Parameter genutzt, wie bei System.pas

[himitsu]

Wer sagt, daß sie DIESE Units überhaupt kompilieren?
Die System.dcu wurde ja auch nicht aus der System.pas erstellt.

[nicodex]

Zitat:

Zitat von Dezipaitor

Was ich nicht verstehe, wie können die von Emb. die Unit kompilieren?

Keine Ahung wie das bei Delphi 2009 ist, aber in älteren Versionen kann man es im $(DELPHI)\Source\Win32\RTL\MakeFile nachlesen.

[Daniel]

Das MakeFile ist da, aber ausgerechnet diese beiden Kandidaten (Generics*.pas) sind nicht enthalten.

Ich habe meine Versuche für den Momen auch eingestellt - mit dem Speicherleck kann ich leben, die Objekt sind in meinem Fall sehr langlebig und für das Iterieren über die Keys habe ich einen Workaround. Das ist gewiss alles nicht befriedigend, aber ich musste hier erstmal weiterkommen.

[turboPASCAL]

Mir würde erst mal einfallen bei den Entwicklern nachzufragen. Das ist doch eine Supportsache wenn die das Speicherleck versämmelt haben. :gruebel:

[jbg]

Zitat:

Zitat von turboPASCAL

wenn die das Speicherleck versämmelt haben.

Wenn es nur das Speicherleck wäre. Die gesamte Unit sieht mehr nach "nicht wirklich getestet" aus. Das liegt vielleicht daran, dass der Compiler bei Generics im allgemeinen etwas instabil ist und somit die Unit auf "hörensagen" entwickelt wurde.

[hanspeter]

Zitat:

Zitat von jbg

Wenn es nur das Speicherleck wäre. Die gesamte Unit sieht mehr nach "nicht wirklich getestet" aus. Das liegt vielleicht daran, dass der Compiler bei Generics im allgemeinen etwas instabil ist und somit die Unit auf "hörensagen" entwickelt wurde.

Ist doch schon seit D5 so, eine neue Version ist erst nach SP2 produktiv verwendbar.

Peter

[himitsu]

Hat hier denn nochmal wer weitergemacht?
(abgesehn von einem Virusentwickler :roll: )

Manchmal macht es wirklich keinen Spaß, wenn einem "ständig"
delphieigene Units unterkommen, welche mit Debuginformationen kompiliert wurden, OBWOHL es die Release-Versionen sein sollten ... ist z.B. nett, wenn man mit F7 sonstwo landet, aber nicht da wo man wollte.
(bei den Indys sind beide "Versionen" sogar komplett identisch und vollgestopft mit Debugzeugs)



Soein Programm, welches du DCU anhand iherer SourceCodes (wenn sie denn vorhand sind) neu kompiliert,
wäre ja eigentlich ganz praktisch. Auch wenn man, wie Daniel mal seine Sourcen etwas editiert.
Oder wie wäre es mit einigen FixupPacks von jbg direkt integriert?


Und vorallem, was sollte wo eigentlich reingehören

Code:

.    Debug         Release        (für die OH, sonst findet man da ja nix)
++   -$C+          -$C-           $ASSERTIONS
+-   -$D+          -$D-           $DEBUGINFO
++   -$G+          -$G-           $IMPORTEDDATA
++   -$I+          -$I-           $IOCHECKS
+-   -$L+          -$L-           $LOCALSYMBOLS
--   -$M+          -$M-           $TYPEINFO
--   -$Q+          -$Q-           $OVERFLOWCHECKS
--   -$R+          -$R-           $RANGECHECKS
--   -$W+          -$W-           $STACKFRAMES
+-   -$Y+          -$Y-           $REFERENCEINFO (hier gibt's ja auch noch -$YD)
+-   -DDEBUG
     --inline:off  --inline:auto

ganz vorne sind die Standardeinstellungen aus den Projektoptionen
und ansonsten isses so, wie ich es eventuell gedenke machen zu werden

im Anhang nur mal 'nen kleiner Anfang/Test
die Units selber würden sich also erstmal kompilieren lassen
(ob sie dann auch laufen müßte man dann mal sehn)
und das mit den Packages hab ich mir noch nicht angesehn



hier wäre es eigentlich auch praktisch, Borcodero für eigene Anwendungen 3 (4) Standard-Versionen anbieten würde und nicht nur die 2 (Debug und Release)
- debuggen ohne Codeoptimierung und mit allen möglichen Zusatzinfos
- debugen mit debuginfos, aber der Code so wie im Release (ohne Asserts, Überlauftests, ...)
- das Release ohne alles

vielleicht noch 'nen Release mit Asserts, Überlauftests, ... und ohne Debuginfos