Finalbuilder: Verschiedene $Config und $Platform bei externen Komponenten

[TiGü]

Hallo zusammen,

wie habt ihr folgendes Problem in euren Buildtools gelöst?

Wir sind von jetzt endlich von 2009 auf XE3 umgestiegen und unserer ALM hadert mit den neuen Möglichkeiten.
Früher gab es nur zwei Optionen: Plattform Win32 mit Debug- und Release-Konfigurationen.

Mit XE3 kommt zusätzlich Win64 hinzu.

Bisher wurden die HPP, DCU, BPL, DCP, BPI und LIB-Dateien einfach zu den Sourcen (PAS, DFM) auf den Buildrechner hinzugeschmissen und der Build fertiggestellt.

Nun will unserer ALM das fein säuberlich getrennt haben in eigene Ordner:
Relase_Win32, Relase_Win64, Debug_Win32, Debug_Win64

Unserer ALM will zuerst die Komponenten builden, in allen vier Variationen und dann erst die richtigen Programme/Projekte, die die Komponenten benötigen, in einen einzigen Durchlauf des Buildprozesses.

Er schlägt nun vor, dass die bisherigen leeren Einträge in den Projektoptionen der Komponentenprojekte (Delphi Compiler -> DCP output directory, Package output directory, Unit output directory) angepasst werden müssen.
Demzufolge müssten auch die globalen Suchpfade in den IDEs aller beteiligten Entwickler angepasst werden, weil nichts mehr unter in den angestammten $(BDSCOMMONDIR) steht.

Ich halte das für keine praktiable Lösung!
Aber mein Versuch das Ganze im FinalBuilder abzuhandeln wurde strikt abgelehnt.
In meinen Augen sind beide Möglichkeiten mit Arbeit verbunden, nur wäre eine Änderung der Standardpfade der IDE bei jeder Neuinstallation (für bspw. neue Entwickler) ein ziemlicher Fackelzug.

Wie habt ihr das gelöst?

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1215304)

Wie habt ihr das gelöst?

FinalBuilder :)

[TiGü]

Zitat:

Zitat von Uwe Raabe (Beitrag 1215307)

Zitat:

Zitat von TiGü (Beitrag 1215304)

Wie habt ihr das gelöst?

FinalBuilder :)

Also angenommen, ihr nutzt die Komponente Virtual Treeview für Delphi/C++:

Habt ihr da pro Config + Platform ein eigenes Final Builder Projekt? Also deren vier?

Hat das FinalBuilder-Projekt für die Ausgabeverzeichnisse eigene Einträge oder nimmt es die aus der Projektdatei der Komponente?

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1215312)

Also angenommen, ihr nutzt die Komponente Virtual Treeview für Delphi/C++:

Habt ihr da pro Config + Platform ein eigenes Final Builder Projekt? Also deren vier?

Hat das FinalBuilder-Projekt für die Ausgabeverzeichnisse eigene Einträge oder nimmt es die aus der Projektdatei der Komponente?

Nein. Es gibt nur ein FinalBuilder-Projekt mit diversen Action-Lists. Eine davon erzeugt über geschachtelte Iteratoren alle nötigen Ausprägungen für alle verwendeten Projekte - natürlich mit den entsprechenden Zielverzeichnissen. Da das FinalBuilder-Projekt innerhalb des CI-Prozesses läuft, sind die Verzeichnisse alle relativ zu einem Basis-Verzeichnis angegeben, das dem FB übergeben wird (das ist bei Start des Projekts immer leer).

Manche Sachen lassen sich in der Delphi-Compiler-Action im FB nicht so leicht variabel über den Dialog angeben. In dem Fall verwende ich dann einen Skript-Event.

Die Suchpfade werden aus der Projektdatei genommen, da die ja mit versioniert werden. Grundsätzlich sind alle Pfade in der dproj relativ. Damit kann ich ein Projekt in ein beliebiges Verzeichnis auschecken und sofort compilieren. Das ist besonders dann wichtig, wenn man mal auf einen älteren Stand zurückgreifen muss. Problematisch dabei sind nur die aktuellen Komponenten in der IDE - da arbeite ich noch an einer brauchbaren Lösung.

Eigentlich konnte ich bisher alles ziemlich komfortabel mit FB lösen (mit der Professional-Version). Einchecken von Code führt automatisch zu einem Continuous Build mit Tests. Eine neue Version wird über einen Mausklick erzeugt und optional auch im Web bereitgestellt. Es dauert zwar eine Weile, bis man das alles fehlerfrei am Laufen hat, aber wenn es dann läuft braucht man sich nicht weiter kümmern. In beiden Fällen wird übrigens dasselbe FinalBuilder-Projekt aufgerufen - lediglich mit unterschiedlichen Parametern.