Units zu Projekt hinzufügen

[MatthiasR]

Hallo Leute,

ich habe mal eine (vielleicht etwas komische) Frage: was hat man davon, wenn man Units, die man in einem Projekt verwenden möchte, auch diesem Projekt hinzufügt? Ich persönlich habe es bisher immer so gehandhabt, dass ich Units, die ich verwenden möchte, auch ins Projekt mit aufgenommen habe. Es funktioniert aber auch, wenn ich die Dateien nicht dem Projekt hinzufüge alles, solange die Units sich imselben Ordner befinden und gefunden werden. So handhabt es nämlich mein Chef mit Units, die von mir neu erstellt wurden (ins Projektverzeichnis kopieren und einfach usen, ohne "Dateien dem Projekt hinzufügen").

Welche Vorgehensweise ist die richtige und was hat man davon?

[Phoenix]

Die saubere Version ist es, die Units ins Projekt aufzunehmen.
Hat unter anderem den Vorteil, dass sich ein Projekt dann auch auf der Kommandozeile durchcompilieren lässt, ohne dass man einen Rattenschwanz an zusätzlichen Suchpfaden mit als Argument übergeben muss. Stichwort automatisierte Builds.

Eine unstrukturierte Reinkopiererei ohne das Projektfile zu pflegen wäre bei mir im übrigen ein Abmahnungsgrund.

[RavenIV]

Nur weil Dein Chef das so macht, muss es nicht unbedingt richtig sein.
Wie Phoenix schon geschrieben hat: Es funktioniert, ist aber nicht schön und unpraktisch.
Vor allem verliert man irgendwann den Überblick.

[MatthiasR]

OK, danke für die Antworten. Mit der Begründung "Das ist unschön!" brauche ich aber nicht zu kommen, sondern bräuchte schon handfeste Argumente a la "Das und das funktioniert dann nicht, wenn wir unser Vorgehen so beibehalten!".
Klar, die Übersicht geht definitiv verloren, da man auf Anhieb nicht weiß, welche Units nun überhaupt verwendet werden und welche nicht mehr, aber das reicht leider nicht.

Ich werde also mein Vorgehen beibehalten und neue Units grundsätzlich dem Projekt hinzufügen

[RavenIV]

Lies Dir den Beitrag #2 von Phoenix nochmal durch.
Da hast Du eine schlagkräftige Begründung: "Stichwort automatisierte Builds".

[Phoenix]

Zitat von Infect:

Klar, die Übersicht geht definitiv verloren, da man auf Anhieb nicht weiß, welche Units nun überhaupt verwendet werden und welche nicht mehr, aber das reicht leider nicht.

Wieso sollte das nicht reichen?
Willst Du/will Dein Chef jedesmal alle möglichen Projekte komplett Unit für Unit in den uses-Klauseln suchen was betroffen sein könnte wenn sich an einer Unit was ändert? Ein Blick in die Projektdatei würde sonst reichen.

Genauso die Builds: Ihr geht doch nicht Ernsthaft her und baut Eure Produktiv-Builds aus der IDE heraus, oder? Das wär ja glatt ein Grund für eine Fristlose...

Aber wenn es funktioniert, dass man Units mal so reinkopiert und einfach so 'used', dann benutzt ihr wahrscheinlich auch noch nicht mal ein Versionierungstool, oder?

[messie]

Zitat von Phoenix:

Genauso die Builds: Ihr geht doch nicht Ernsthaft her und baut Eure Produktiv-Builds aus der IDE heraus, oder?

Habe ich das falsch verstanden oder sehe ich das wirklich anders? Ich denke, das hängt doch stark von der Größe und Struktur der Aufgabe ab...

Noch eine Frage, die ein Argument für den Chef ergeben könnte: werden denn alle Compilerdirektiven und -einstellungen gleich gehandhabt, wenn ich die Datei nicht ins Projekt aufnehme?


Grüße, Messie

[PMM]

Ich denke, man sollte die Units in das Projekt aufnehmen, wenn sie zum Projekt gehören (also im Projekt bearbeitet werden). Wenn das nicht der Fall ist, schützt das "nicht in das Projekt aufnehmen" davor, diese unbeabsichtigt zu verändern (und damit evtl. unerwünschte Nebeneffekte in aqnderen Projekten zu erzeugen). Solange man alleine, und nur an einem Projekt zu einer Zeit arbeitet, spielt das kaum eine Rolle, aber in einem kleinen Team (in großen Teams gibt es noch ganz andere Probleme...) ist sowas schon wichtig.
PMM

[Phoenix]

Du gibst Dir die Antwort eigentlich schon selber:

z.B. Debugsymbole oder auch Assertions haben in einer für den produktiven Betrieb Erstellen Echse nix zu suchen.
Wenn die produktiven Binaries aus der IDE heraus erstellt werden vergisst man schon das eine oder andere mal den einen oder anderen Compilerschalter. Ergo kann man nie mit Sicherheit sagen, dass die ausgelieferten Binaries mit denen auf der eigenen Maschine identisch sind, was sich insbesondere bei der Fehlersuche massivst rächt.

Hat man definierte Buildjobs, so hat man das Problem nicht. Sourcerevision auschecken, Batch anschmeissen, und man ist sich 100% sicher dass die frisch gebauten Binaries mit denen beim Kunden identisch sind. Macht die Fehlersuche massivst einfacher.