Builder 2010: Relative Pfade statt absolute in 'Include file search path'
-
Hallo zusammen
Wenn ich in meinem Builder 2010 Project einen Pfad in "Include file search path" hinzufüge, wird dieser immer als absoluter Pfad eingetragen. Das ist natürlich sehr mühsam, wenn der ganze Projektordner verschoben wird (zb. zum Kollegen, der auf einem anderen Vz wie ich entwickle).
Wie kriege ich dies gebacken, dass ich nicht jeden Pfad nach dem zufügen noch manuell bearbeiten und daraus einen relativen Pfad machen muss? Gibts irgendwo eine Einstellung, die ich noch nicht gefunden habe.
Vielen Dank für Eure geschätzte Hilfe!
-
aekeller schrieb:
Wenn ich in meinem Builder 2010 Project einen Pfad in "Include file search path" hinzufüge, wird dieser immer als absoluter Pfad eingetragen. Wie kriege ich dies gebacken, dass ich nicht jeden Pfad nach dem zufügen noch manuell bearbeiten und daraus einen relativen Pfad machen muss?
Ich verwende meist direkt relative Pfade, dann gehts. Wie weit weg ist denn das einzubindende Verzeichnis bei dir? Je weiter er ausschweift, also je weiter er sich von nur zum Projekt gehörigen Verzeichnissen entfernt, desto instabil wird so ein relativer Pfad; da schwindet der Scheinvorteil gegenüber einem absoluten Pfad doch sehr schnell.
Sehr hilfreich beim Verzeichnismanagement sind übrigens Junctions (ab Windows 2000) oder Symbolic Links (ab Vista); für die Explorer-Integration gibt es die Link Shell Extension. Ich habe so ziemlich alle 3rd-party-Software entweder direkt unter $(BDSPROJECTSDIR)\repository\<Projektname> installiert oder per Junction dort verlinkt. Da muß ich nicht viel tippen, und es ist egal, wo das Projekt selbst liegt. Projektinterne Pfade liegen üblicherweise nicht weiter als zwei Schritte entfernt, so daß es nicht problematisch ist, einen relativen Pfad eingeben zu müssen.
Edit: Quotes repariert
-
Die Situation beim mir stellt sich folgendermassen: Ich habe zwei Rootverzeichnisse:
D:\DEV und D:\PRODDarunter sind alle Programme und Komponenten, jeweils einmal in einer Entwicklungsversion und einmal in der Produktiven Version. Wenn nun ein Programm von D:\DEV\progiX nach D:\PROD\progiX überführt wird, dann werden halt weiterhin die Entwicklungs-Headers inkludiert... Ok, mit einem grep ging die Umsetzung auch, aber ist halt mühsam. Mein Kollege zum Beispiel hat seine Versionen und E:\DEV und E:\PROD....
Wohl hilft nichts und wir müssen uns die relativen Pfade herbasteln.
Oder ist es möglich, ein einer Datei alle Inklude-Pfade abzulegen und diese dann zu verwenden:
----IncludePathDev.txt----
`E:\DEV\incAE:\DEV\incA\sub
E:\DEV\incB
...`
--------------------IncludePathDev.txt----
`E:\PROD\incAE:\PROD\incA\sub
E:\PROD\incB
...`
----------------In den Entwickungsprojekten würde ich dann in den Pfads aus IncludePathDev.txt suchen, in den Prod-Projekten analog in IncludePathDev.txt.
Die Drittprodukte habe ich separat in einen Verzeichnis. Die stellen noch kein Problem dar.
-
aekeller schrieb:
Die Situation beim mir stellt sich folgendermassen: Ich habe zwei Rootverzeichnisse:
D:\DEV und D:\PRODDarunter sind alle Programme und Komponenten, jeweils einmal in einer Entwicklungsversion und einmal in der Produktiven Version.
Nur aus Neugier, wozu macht ihr das? Was sind das für gravierende Unterschiede, die einer Verwaltung in separaten Verzeichnissen erfordern?
aekeller schrieb:
Oder ist es möglich, ein einer Datei alle Inklude-Pfade abzulegen und diese dann zu verwenden:
Ja - das geht mit Option Sets/Optionsgruppen:
http://docwiki.embarcadero.com/RADStudio/de/%C3%9Cbersicht_%C3%BCber_Optionsgruppen
-
audacia schrieb:
aekeller schrieb:
Die Situation beim mir stellt sich folgendermassen: Ich habe zwei Rootverzeichnisse:
D:\DEV und D:\PRODDarunter sind alle Programme und Komponenten, jeweils einmal in einer Entwicklungsversion und einmal in der Produktiven Version.
Nur aus Neugier, wozu macht ihr das? Was sind das für gravierende Unterschiede, die einer Verwaltung in separaten Verzeichnissen erfordern?
Unser Produkt besteht aus etwa 30 Exe-Dateien. Diese verwenden eine Auswahl aus insgesamt 70 DLLs. Alle sind mehr oder weniger abhängig voneinander - jedoch nicht zyklisch ;-). Als Sourcenverwaltung setzen wir - immer noch - VSS ein. Da dauert es halt sehr lange, um einen bestimmten mit Labeln versehenen Stand abzurufen. Da haben wir uns mal entschieden, dass wir zwei VSS-Datenbanken führen, eine mit dem "aktuellen" Entwicklungsstand und eine mit dem aktuellen Produktionsstand. Muss nun in der Produktion ein Fix gemacht werden, müssen wir nicht immer den Entwicklungsstand sichern und den Produktionsstand abbrufen, den Fix erstellen auf dem Produktionsstand etc. Wir können so unseren Entwicklungsstand lassen wie er ist und parallel am Produktionsstand operieren. So kann der Fehler meistens mit einem kleinen Eingriff behoben werden und es braucht lediglich eine DLL oder eine EXE ausgeliefert zu werden. Unsere Kunden zieren sich immer ziemlich, alle DLLs und EXEs neu einzuspielen - wohl aus schlechten Erfahruzngen
Alles ist natürlich historisch etwas gewachsen. Gerne würden wir das über Bord werfen. Dazu müssen wir aber die Sourcenverwaltung wohl ablösen und da scheuen wir den Aufwand. Momentan versuchen wir den Umstieg von CB2007 auf CB2010 zu schaffen, was ja mit der Unicode-Umstellung auch nicht ohne ist.
Frage beantwortet? Wenn nicht, frage gerne nach. Wir verbessern uns sehr gerne und evtl. können wir in anderen Dingen inspirieren.
audacia schrieb:
aekeller schrieb:
Oder ist es möglich, ein einer Datei alle Inklude-Pfade abzulegen und diese dann zu verwenden:
Ja - das geht mit Option Sets/Optionsgruppen:
http://docwiki.embarcadero.com/RADStudio/de/%C3%9Cbersicht_%C3%BCber_OptionsgruppenVielen Dank für diesen Hinweis. Ist wohl gerade das was wir gesucht haben. Super!
-
aekeller schrieb:
Als Sourcenverwaltung setzen wir - immer noch - VSS ein. Da dauert es halt sehr lange, um einen bestimmten mit Labeln versehenen Stand abzurufen. Da haben wir uns mal entschieden, dass wir zwei VSS-Datenbanken führen, eine mit dem "aktuellen" Entwicklungsstand und eine mit dem aktuellen Produktionsstand.
VSS? Das würde ich mal schnellstmöglich ändern
Du könntest es ja mal mit Mercurial oder SVN versuchen:http://stackoverflow.com/questions/961878/moving-from-visual-sourcesafe-to-mercurial
Wie gut das funktioniert, weiß ich allerdings nicht.aekeller schrieb:
Frage beantwortet?
Ja! Allerdings würde ich unabhängig von deiner Problematik projektinterne Verzeichnisverweise immer relativ angeben. Gut strukturiert ist ein Projekt dann, wenn ich es auf einem beliebigen Rechner in ein beliebiges Verzeichnis auschecken und kompilieren kann; das sollte die Zielsetzung sein. Mir ist bewußt, daß das bei derart umfänglichen Projekten nicht so trivial ist, aber relative Pfade sind immerhin ein Schritt in die richtige Richtung.
Verwendet ihr denn Continuous Integration?
-
audacia schrieb:
VSS? Das würde ich mal schnellstmöglich ändern
Du könntest es ja mal mit Mercurial oder SVN versuchen.Tja, History halt... Wir sind momentan am Testen von Subversion. Mal sehen. Allerdings scheint mir der Ruf von VSS wesentlich schlechter wie es effektiv ist. Funktioniert bei uns schon seit längerem mehr oder weniger problemlos.
audacia schrieb:
Allerdings würde ich unabhängig von deiner Problematik projektinterne Verzeichnisverweise immer relativ angeben. Gut strukturiert ist ein Projekt dann, wenn ich es auf einem beliebigen Rechner in ein beliebiges Verzeichnis auschecken und kompilieren kann; das sollte die Zielsetzung sein. Mir ist bewußt, daß das bei derart umfänglichen Projekten nicht so trivial ist, aber relative Pfade sind immerhin ein Schritt in die richtige Richtung.
Das war bei uns bisher immer das höchste Gebot. War ein guter Weg und hat sich gelohnt.
audacia schrieb:
Verwendet ihr denn Continuous Integration?
Gemäss Defintion aus http://de.wikipedia.org/wiki/Kontinuierliche_Integration nicht. Wir machen jedoch Nightly-Builds und Smoketest. Dies jede Nacht und das für die "Entwicklung", die "Produktion" und die "PreDistribution", dh. die kommende resp. die nächste Produktion. Dazu setzen wir FinalBuilder ein (http://www.finalbuilder.com)
