dproj-Datei und absolute Pfade

[SneakyBagels]

Mir sind gerade in einer dproj-Datei absolute Pfade von ICO-Dateien entgegengesprungen.

Z.B. <UWP_DelphiLogo44> und <UWP_DelphiLogo150>.

Gibt es eine Möglichkeit Delphi davon zu überzeugen, hier relative Pfade zu verwenden?
Und sind diese beiden ICO-Dateien eigentlich bei normalen Windows-Executables, die keine Win10-App sind notwendig?

[Uwe Raabe]

Zitat von SneakyBagels:

Mir sind gerade in einer dproj-Datei absolute Pfade von ICO-Dateien entgegengesprungen.

Z.B. <UWP_DelphiLogo44> und <UWP_DelphiLogo150>.

Gibt es eine Möglichkeit Delphi davon zu überzeugen, hier relative Pfade zu verwenden?

Nicht das ich wüsste. Auch das manuelle Entfernen des Pfads hilft nicht, da die IDE beim Öffnen des Projekts die Logos im falschen Verzeichnis sucht.
Dabei handelt es sich aber offensichtlich um einen Bug. Machst du dafür einen QP-Eintrag auf?

Zitat von SneakyBagels:

Und sind diese beiden ICO-Dateien eigentlich bei normalen Windows-Executables, die keine Win10-App sind notwendig?

Nein, sind sie nicht. Du kannst die absoluten Pfade ganz einfach entfernen, wenn du unter Projekt - Optionen - Anwendung in der passenden Build-Konfiguration bei den beiden Logos auf den Vorgabe-Button klickst.

[SneakyBagels]

Zitat:

Nein, sind sie nicht. Du kannst die absoluten Pfade ganz einfach entfernen, wenn du unter Projekt - Optionen - Anwendung in der passenden Build-Konfiguration bei den beiden Logos auf den Vorgabe-Button klickst.

Ok heißt also, solange ich keine Win10-App entwickle, brauche ich diese Icons gar nicht.

Ich versuche mich heute Abend mal mit meinem gebrochenem Denglish um einen QR-Eintrag zu kümmern.

[ventiseis]

Eine Idee wäre, mit SUBST ein virtuelles Laufwerk anzulegen. So kann man bei allen Entwicklern gleiche Pfade verwenden, alle Sourcen haben einen einheitlichen Pfad - egal ob absolut oder relativ. Funktioniert bei uns seit Jahren ohne Probleme. Auch das Umschalten zwischen unterschiedlichen Arbeitskopien geht dann schnell: einfach den durch SUBST zugeordneten Verzeichnisbaum austauschen.

Zusätzliche Anmerkung: auch unter Windows 10 funktioniert SUBST noch.

[SneakyBagels]

Nur

Zitat:

Ok heißt also, solange ich keine Win10-App entwickle, brauche ich diese Icons gar nicht.

?

[Uwe Raabe]

Zitat von ventiseis:

Eine Idee wäre, mit SUBST ein virtuelles Laufwerk anzulegen. So kann man bei allen Entwicklern gleiche Pfade verwenden, alle Sourcen haben einen einheitlichen Pfad - egal ob absolut oder relativ.

Dieses Verfahren hatte ich früher (vor über 10 Jahren) auch schon mal angewendet, bin dann aber bei relativen Pfaden für das ganze Projekt gelandet. Das hat den Vorteil, daß ich gleichzeitig mehrere Pfade mit demselben Projekt in unterschiedlichen Zuständen (z.B. Branches) aktiv haben kann und einfach in der IDE die Projektgruppe umschalten kann. Das ist ganz hilfreich, wenn man spontan einen Bug in einer älteren Version nachvollziehen soll, seinen aktuellen Stand aber nicht antasten möchte. Ich kann auch mehrere IDE-Instanzen aufmachen und diese Projekte z.B. gleichzeitig debuggen. Das lässt sich mit dem SUBST-Ansatz nicht verwirklichen.

Meine Projektverzeichnisse sind in der Regel nach diesem Schema aufgebaut: Im Root-Verzeichnis liegen die Projektdateien, die Projektgruppen und ein paar automatisch vom System dort erwartete Units (z.B. die _TLB.pas). Die Units sind gemäß der Programm-Architektur in verschiedenen Unterverzeichnissen angeordnet. Weiterhin gib es ein lib-Unterverzeichnis für die verwendeten Bibliotheken (als HG-SupRepos - siehe oben Bug in älterer Version). Dann gibt es noch ein OptSet mit den Suchpfaden und Zielpfaden (beide relativ), das von allen Projekten dieser Projektgruppe (auch Mehrzahl) verwendet wird (hält den Pflegeaufwand in Grenzen). Da die Projekte alle im Stammverzeichnis liegen, passen die relativen Pfade für alle Projekte. Da alle für das Projekt benötigten Dateien im Stammverzeichnis oder darunter liegen, kann ich das Projektverzeichnis einfach auf ein anderes Verzeichnis klonen (oder auch kopieren, wenn man das unbedingt will). Brauche ich das Projekt auf einem anderen Rechner, genügt ebenfalls ein einfaches Clone und ich habe ohne weiteres Zutun wieder ein compilierbares Projekt. Name und Position des Projektverzeichnisses sind da vollkommen egal.

Wie dieser Thread aber auch zeigt, muss man immer aufpassen, daß einem die IDE nicht einen Strich durch die Rechnung macht. Bei den Win10-App Logos hat offenbar noch einer gepennt. Deswegen ist es wichtig, daß dies bei Embarcadero in das QP kommt. Sonst wird das nie behoben.

[SneakyBagels]

Zitat:

Bei den Win10-App Logos hat offenbar noch einer gepennt.

Ohne diesen Fehler wäre ein Projektverzeichnis zu 100% portabel. Wegen des Fehler ist er es leider aber nicht und man bekommt sofort Fehler um die Ohren, wenn man das Verzeichnis verschiebt und anschließend die Projektoptionen öffnet.

[ventiseis]

Zitat von Uwe Raabe:

Ich kann auch mehrere IDE-Instanzen aufmachen und diese Projekte z.B. gleichzeitig debuggen. Das lässt sich mit dem SUBST-Ansatz nicht verwirklichen.

Das ist in der Tat ein wesentlicher Vorteil. Allerdings bräuchte ich dann auch ein Tool, das Altlasten "von früher" in den Projektdateien aufräumt.

Zitat von Uwe Raabe:

Dann gibt es noch ein OptSet mit den Suchpfaden und Zielpfaden (beide relativ), das von allen Projekten dieser Projektgruppe (auch Mehrzahl) verwendet wird (hält den Pflegeaufwand in Grenzen).

Das gefällt mir auch sehr gut. Unsere Idee, die Suchpfade in den allgemeinen Delphi-Optionen über ein Tool direkt in die Registry zu schreiben, ist sicher nicht so elegant.

Zitat von Uwe Raabe:

Wie dieser Thread aber auch zeigt, muss man immer aufpassen, daß einem die IDE nicht einen Strich durch die Rechnung macht.

Das stimmt, hier klemmt es ab und zu. Manche Dinge funktionieren einfach nicht so richtig, aber das wurde ja schon oft besprochen. Angefangen vom DPROJ-Normalizer bis hin zu fehlenden Inhalten waren die Projektdateien schon oft Gegenstand von Diskussionen und Verbesserungsideen.