Buildnummer weiterzählen

[Frickler]

Woran kann es liegen, dass bei aktivierter Einstellung "Buildnummer erhöhen" die Buildnummer nicht immer weitergezählt wird?
Bei den meisten Projekten funktioniert es, aber bei einigen wenigen Projekten gehts immer erst im 2. Versuch.
Und noch merkwürdiger: bei manchen Projekten ist nach dem 2. Mal Build die Buildnummer dann um 2 hochgezählt, und bei anderen um 1.

Und noch viel merkwürdiger: das zieht sich inzwischen durch die dritte Delphi-Version: es war so bei XE, bei XE6 und jetzt bei 10.2. Bei beiden Umstellungen habe ich jeweils die DPROJ Dateien komplett neu erstellt, also nicht übernommen.


Nachtrag: bei 10.2 ist es seltener geworden. Auch die früher notorischen Nicht-Weiterzähler zählen inzwischen meist weiter.

[Uwe Raabe]

Das kann passieren, wenn man in unterschiedlichen Buildkonfigurationen (Debug, Release) diese Option aktiviert hat, anstatt nur in der Basis- bzw. Basis/Plattform-Konfiguration.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1510675)

Das kann passieren, wenn man in unterschiedlichen Buildkonfigurationen (Debug, Release) diese Option aktiviert hat, anstatt nur in der Basis- bzw. Basis/Plattform-Konfiguration.

Aktiviert ist es in allen Projekten gleich: in der Basis (win32). Ich muss dann nur jeweils noch in der Debug-Version die Sprache umstellen. Diese Einstellung wird nämlich nicht übernommen. Warum auch immer...

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1510687)

Aktiviert ist es in allen Projekten gleich: in der Basis (win32).

Prüf doch bitte mal, in welche Konfiguration sich die Buildnummer erhöht nach einem Build. Basis oder Debug/Release?

[Rolf Frei]

Zitat:

Zitat von Uwe Raabe (Beitrag 1510675)

Das kann passieren, wenn man in unterschiedlichen Buildkonfigurationen (Debug, Release) diese Option aktiviert hat, anstatt nur in der Basis- bzw. Basis/Plattform-Konfiguration.

Wenn das so funktionieren würde, wäre das toll. Aber es tut eben nicht so. Wenn ich unter Alle Konfigurationen/Win32 Plattform das einstelle, werden mir dann die Versionsbuildnummer Einträge under Release/win32 und Debug/Win32 geändert und ab da gilt dann der Eintrag auf alle Konfiguraton nicht mehr. Das funktioniert einfach nicht so wie es sein sollte. Zwar hat man hier eine paar Anpassungen in D11 gemacht aber mit den automatischen Hochzählen funktioner das einfach immer noch nicht richtig. Ich möchte eigentlich unter Debug/Release nichts Versionsabhängiges drin haben, aber leider trägt die IDE da immer wieder Sachen ein, die dann nicht mehr von oben genommen werden. Bei Release und Debug solle keien Einträge geändert werden, sonst bin ich wiede dazu verdammt, zwei unterschiedliche Verisonen pflegen zu müssen (Release und Debug).

[Uwe Raabe]

Zitat:

Zitat von Rolf Frei (Beitrag 1510697)

und ab da gilt dann der Eintrag auf alle Konfiguraton nicht mehr.

Genau dafür gibt es eine Option im ProjectMagician.

[Rolf Frei]

Ok schau mir da dein Tool mal an, aber eigentlich sollte sowas von der IDE korrekt gemacht werden, ohne dass man da auf externe Tools zurückgreiffen muss.

[Frickler]

Ich kompiliere immer nur auf Debug. Ist vielleicht nicht so gedacht, aber ich hatte mit den erzeugten Programmen nie Probleme.

Bei einem der Problembären ist es nach einem Build (XE6) so: in der EXE Datei ist die Build-Nummer 139. In den Projekteinstellungen unter Versionsinformationen ist sie im Debug-Modus 140 und in Basis sowie Release 137. Ich kann jetzt unendlich oft kompilieren, die Nummer in der EXE bleibt bei 139, also nicht 140, wie es in der Konfiguration sichtbar ist.
Nach einem erneuten Build ist die Version sowohl in den Projekteinstellungen (Debug) als auch in der EXE 141. Basis und Release bleiben bei 137.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1510699)

Zitat:

Zitat von Rolf Frei (Beitrag 1510697)

und ab da gilt dann der Eintrag auf alle Konfiguraton nicht mehr.

Genau dafür gibt es eine Option im ProjectMagician.

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

[Uwe Raabe]

Zitat:

Zitat von Rolf Frei (Beitrag 1510700)

Ok schau mir da dein Tool mal an, aber eigentlich sollte sowas von der IDE korrekt gemacht werden, ohne dass man da auf externe Tools zurückgreiffen muss.

Da stimme ich dir zu, wie so manch anderer sicher auch:
https://quality.embarcadero.com/browse/RSP-23402
https://quality.embarcadero.com/browse/RSP-10809
https://quality.embarcadero.com/browse/RSP-19662
https://quality.embarcadero.com/browse/RSP-38153
https://quality.embarcadero.com/browse/RSP-37058
https://quality.embarcadero.com/browse/RSP-18219

Ich wollte halt nicht länger warten. Immerhin gibt es die Möglichkeit, solche Dinge durch ein externes Tool zu lösen.

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1510703)

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:

Zitat von Rolf Frei (Beitrag 1510709)

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:

Zitat von Uwe Raabe (Beitrag 1510714)

Zitat:

Zitat von Rolf Frei (Beitrag 1510709)

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:

Zitat von Rolf Frei (Beitrag 1510775)

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.