Buildnummer weiterzählen

[Uwe Raabe]

Zitat von Frickler:

Project Magician habe ich, aber welche Option soll das sein? Das Tool ist - zumindest für mich - nicht selbsterklärend.

Deswegen gibt es ja auch einen Eintrag in Hilfe - Hilfe von Drittherstellern.

Auch der verlinkte Blog-Artikel spricht genau dieses Thema an.

Wenn du das Tool schon im Einsatz hast, alles richtig eingestellt ist und es trotzdem nicht wie erwartet funktioniert: Wenn ich es hier reproduzieren kann und es mit vertretbarem Aufwand umsetzbar ist, kriegen wir das auch noch hin.

[Rolf Frei]

Habe es nun installiert, aber funktionieren tut es immer noch nicht oder ich mache was falsch. Habe da bei den Project Settings unter "Clear settings in child configs" nur "Version info" ausgewählt, sonst nichts. Dann habe in den normalen Projektoptionen unter Alle Konfigurationen/Win32 die ganzen Verisoneinstellugen nach Wunsch angepasst. "Auto increment build number" ist da eingestellt.

Wenn ich nun einen Build mache werden mir dennoch die Einträge under Debug/Release aktualisiert und an den Einstellungen unter Alle Konfiguration/win32 wird die Build Number nicht erhöht. Sollte das Tool das nicht bei einem Build automatisch machen, dass die Buildnumber jeweils oben aktualisiert werden und die Einträge unten (Debug/Rel) gelöscht werden? Deine Hilfedatei bringt mich auch nicht weiter. Was mache ich falsch? Irgendiwe hat sich da überhaupt nichts verändert, gegenüber vorher.

[Uwe Raabe]

Zitat von Rolf Frei:

Wenn ich nun einen Build mache werden mir dennoch die Einträge under Debug/Release aktualisiert und an den Einstellungen unter Alle Konfiguration/win32 wird die Build Number nicht erhöht.

Ich muss gestehen, dass ich dieses Szenario noch nicht ausprobiert habe, weil ich die Buildnummern immer in meinem externen Build-System verwalte und mit der Versionsverwaltung synchronisiere. Das Build aus der IDE verwende ich eher zur Herstellung eines sauberen Compilats.

Insofern nimmt das Tool auch keinen Einfluss auf die von der IDE erzeugten Build-Nummern, noch wo diese gespeichert werden. Könnte es aber. Ich werde das mal bei Gelegenheit analysieren.

[Sinspin]

Wir verwenden auch nur noch die Revisionsnummer aus der Versionsverwaltung. Es ist damit wer letztendlich übersetzt und ausliefert.
Denn die Projektdateien checken wir allesammt nicht ein um das Caos in Grenzen zu halten was beim zusammenführen sonst zwangsläufig entstehen würde.

[himitsu]

Wir nehmen die Versionsnummer aus Git und gleichzeitig noch Branchname+Datum (Hash) des HauptRepos (beim Start mit angezeigt) und und einer Deteilanzeige aller Teil-Repos als Ressource und im Info-Dialog mit auf ... da weiß man immer genau woraus was besteht, um z.B. nachträglich in alte Versionen Teil-Erweiterungen machen zu können.

Wird im FinalBuilder ausgelesen, damit eine .RC gebaut und Diese dann compiliert.

[Rolf Frei]

Zitat von Uwe Raabe:

Zitat von Rolf Frei:

Wenn ich nun einen Build mache werden mir dennoch die Einträge under Debug/Release aktualisiert und an den Einstellungen unter Alle Konfiguration/win32 wird die Build Number nicht erhöht.

Ich muss gestehen, dass ich dieses Szenario noch nicht ausprobiert habe, weil ich die Buildnummern immer in meinem externen Build-System verwalte und mit der Versionsverwaltung synchronisiere. Das Build aus der IDE verwende ich eher zur Herstellung eines sauberen Compilats.

Insofern nimmt das Tool auch keinen Einfluss auf die von der IDE erzeugten Build-Nummern, noch wo diese gespeichert werden. Könnte es aber. Ich werde das mal bei Gelegenheit analysieren.

Ja wenn du da was machen könntest wäre das super! Aktuell nutzt mir dein Tool leider garnichts, da sich damit nichts geändert hat. Was ich aber gerne noch wüsste ist, wann das eingestellte Zeugs denn überhaupt gemacht wird. Beim Speichern? Beim Laden? Beim Kompilieren?

[Uwe Raabe]

Zitat von Rolf Frei:

Was ich aber gerne noch wüsste ist, wann das eingestellte Zeugs denn überhaupt gemacht wird. Beim Speichern? Beim Laden? Beim Kompilieren?

Aktuell reagiert es auf das Öffnen und Speichern von Units und Projektdateien und beim Wechsel des Projekts. Was wann gemacht wird hängt von der jeweiligen Option ab.

Die Hauptaufgabe ist die Normalisierung der dproj-Datei um die Versionsverwaltung einfacher zu machen. Zumindest in nicht ganz aktuellen Delphi-Versionen genügt schon ein Laden und Speichern eines Projekts um Änderungen in der dproj-Datei hervorzurufen. Das wird durch eine konsistente Sortierung vermieden.

Das Splitten der dproj-Datei basiert auf der gleichen Anforderung allerdings unter dem Aspekt der Arbeit im Team. In der dproj-Datei werden diverse Einträge gemacht, die sich auf das System des aktuellen Entwicklers beziehen oder von ihm bewusst geändert wurden, ohne eine Absicht, die an die anderen Team-Mitglieder weiterzugeben (z.B. Aufruf-Parameter, Debugger-Einstellungen, aktuelle Konfiguration oder Plattform). Diese Änderungen werden beim Speichern aus der dproj extrahiert und lokal abgespeichert. Beim nächsten Öffnen werden die dann wieder eingepflegt.

Die Einträge für Excluded Packages werden automatisch an die aktuelle IDE angepasst. Arbeitet man auf verschiedenen Systemen oder mit unterschiedlichen Registry Keys ändert sich das dauernd. Deswegen werde die komplett entfernt.

Clear Settings in Child Configurations greift ein Problem der IDE auf, die eine Vererbung von Einstellungen in der Hierarchie der Build-Konfigurationen nicht sinnvoll manipulieren kann, wie es z.B. bei den Compiler-Optionen der Fall ist. Das betrifft insbesondere die Versions-Info, aber auch die Einstellungen für Packages und Applications. Hier werden einfach alle vererbten Einstellungen gelöscht, so dass immer die Basis-Einstellung Gültigkeit hat. Manche Einstellungen erfordern eine Plattform - dann gilt die entsprechende Plattform-Basis Konfiguration.

Platforms: Enable Missing macht dem Projekt alle Plattformen hinzu, die in der aktuellen IDE Version bekannt sind (auch wenn nicht installiert). Damit lassen sich auch bei alten Projekte die neuen Plattformen hinzufügen.

Platforms: Remove Unused entfernt alle Einträge für Plattformen, die in dem Projekt nicht aktiv sind. Bei einem Aktivieren einer Plattform würden die eh neu erzeugt werden.

Auto LibSuffix setzt das LIBSUFFIX für das Package-Projekt auf die des rtl-Packages.

Refresh Form Type ergänzt fehlende DFM und FMX in Form-Einträgen, was zu einem Problem beim Hinzufügen von Frames führen konnte.

Clean Line Feeds forciert beim Öffnen einer Datei die Zeilenenden auf CR/LF.

Einige dieser Optionen (z.B. Auto LibSuffix, Refresh Form Type, Clean Line Feed) sind in neueren Delphi-Versionen obsolet.

[Rolf Frei]

Danke für deine detailierte Erklärung. Nun hoffe ich nur noch, dass du mal die Zeit findest, das mit der Versions Buildnummer zu lösen. Das wäre für mich, und vermutlich hunderte andere Delphi Nutzer, ein riesiger Gewinn, wenn das dann irgendwann mal so funktioniert wie es erwartet wird.