Draft: Resolve "Pfade zu Ressourcen abhängig von working dir"

Closes #83 (closed)

added 💻 Doing 🤯 Discussion labels

added 6 commits

• de88d427 - [#83 (closed)] add boost
• 44f5fe7d - [#83 (closed)] add Utils to Sources.cmake
• 47f509bd - [#83 (closed)] add Boost.cmake
• e2ac5c7d - [#83 (closed)] add Utils.hpp
• cddf0447 - [#83 (closed)] add Utils.cpp
• 02a13d66 - [#83 (closed)] add example for use of absolutePath function

Compare with previous version

Habe boost::dll::program_location (https://www.boost.org/doc/libs/1_61_0/doc/html/boost/dll/program_location.html) genutzt, um das aktuelle Projektverzeichnis zu erhalten.

Derzeit habe ich Boost 1.76.0 lokal hinterlegt, deswegen läuft die CI-Pipeline nicht durch.
Außerdem wurde bisher nur die main von first_mesh angepasst.

Wenn die Idee zuspruch findend, könnte man das ganze vermutlich auch als submodule ins Repo integrieren.

Um ehrlich zu sein, denke ich nicht, dass wir dafür Boost brauchen. In C++17 wurde std::filesystem ja hinzugefügt und das orientiert sich so stark an Boost, dass es so ziemlich die meisten (wenn nicht sogar alle) Features davon umsetzt.

Wir können also auch Pfade relativ zur Binary ohne Boost machen:

Falls das also ein Feature des Frameworks werden soll, bräuchten wir bloß die Argumente der Anwendung bei der Core-Erzeugung mitzugeben oder ähnlich (Theoretisch könnten wir auch die ersten Stellen im Stack auslesen, aber das wäre echt hacky... ^^').

Ich persönlich hätte allerdings auch kein Problem damit, dass die Pfade von der Anwendung bestimmt werden und die hätte ja definitiv Zugriff auf den Pfad.

ja, ich fand boost jetzt eigentlich auch overkill.

Mit der jetzigen Variante wird nur std::filesystem verwendet. Ist die Frage, ob das mit der globalen Variable doof ist, oder in diesem Fall zulässig. Vorteil ist halt, dass man nicht überall durchreichen muss, was halt in manchen fällen doof ist (Beispiel in der Voxelization.cpp aus dem voxelization project).

Es scheint auch zu gehen, ohne den Pfad aus den Argumenten abzusichern, indem man es über das Process-Management je nach OS ausliest ( https://stackoverflow.com/questions/1528298/get-path-of-executable ).

Ich bin halt nur immer noch nicht sicher, ob man das überhaupt verwenden sollte. Grundsätzlich sollte es eigentlich intuitiver sein, dass Resourcen aus dem working-directory geladen/verwendet werden, als aus dem Ordner in dem die Binary liegt.

Wir können auch gerne alternativ einen Ordner für die Anwendung selbst anlegen, um dort z.B. die geplante Konfigurations-Datei reinzupacken oder auch Caches etc. aber ich sehe keinen Grund wieso man das working-directory übergehen sollte. ^^'

hmm, also ich finde es eher wenig intuitiv, wenn die Anwendung bei eigenen (festen!) Ressourcen abhängig ist vom Pfad, von dem aus invokiert wird xD

Klar, bei Daten, die man dynamisch in die Anwendung läd ist das was anderes, aber wenn man vordefinierte Ressourcen hat, von denen die Ausführbarkeit der Anwendung eine harte Abhängigkeit hat, ist es aus User Sicht ja erstmal völlig uninteressant, was das Working Directory ist.

Ein weiterer Grund ist auch, dass IDEs default das working dir unterschiedlich setzen. Visual Studio setzt beim Run das Working Directory beispielsweise default auf den BinaryPath, VSCode hingegen nicht.

Da könnte dann später bei Verwendung zu Verwirrung der Anwender führen.

Soweit ich das recherchiert hatte, ist beim Vorgehen über Process-Management halt wieder die Cross-Plattform-Problematik gegeben; nicht garantiert, das es geht etc.

Klar, bei Daten, die man dynamisch in die Anwendung läd ist das was anderes, aber wenn man vordefinierte Ressourcen hat, von denen die Ausführbarkeit der Anwendung eine harte Abhängigkeit hat, ist es aus User Sicht ja erstmal völlig uninteressant, was das Working Directory ist.

Vorausgesetzt man startet die Anwendung aus einem Terminal, ist es halt typisch, dass das working-directory verwendet wird. Jede halbwegs brauchbare IDE kann auch das working-directory setzen und im Endeffekt halt ich den generellen Nutzen bei Usern/Entwicklern für größer, wenn sie ein working-directory zu setzen lernen können als unsere Abstraktion zu verwenden. Denn wenn ich trotzdem einen Pfad relativ (unabsichtlich oder nicht) verwenden würde, wäre ich als Nutzer nur mehr verwirrt, wenn wir das 1.) falsch-korrigieren oder 2.) nicht konsistent verwenden.

Zusätzlich ist das working-directory auch bei jedem graphischen Explorer auch automatisch identisch zum Anwendungsverzeichnis, wenn ich es nicht vom Terminal sondern per Maus starten möchte. Da sehe ich auch kein Problem. Verknüpfungen usw. erlauben auch das setzen von working-directory.

Ein weiterer Grund ist auch, dass IDEs default das working dir unterschiedlich setzen. Visual Studio setzt beim Run das Working Directory beispielsweise default auf den BinaryPath, VSCode hingegen nicht.

Es ist ja nicht einmal sinnvoll, dass aktuell der Ordner mit den Assets der Ordner der Anwendung ist. Das ist bloß ein Work-around, damit man in Visual-Studio nicht selbst das working-directory setzen muss. In Clion oder Eclipse ist das halt gar kein Problem das zu trennen und ergibt auch mehr Sinn aufgrund von Debug- und Release-Build.

Soweit ich das recherchiert hatte, ist beim Vorgehen über Process-Management halt wieder die Cross-Plattform-Problematik gegeben; nicht garantiert, das es geht etc.

Es wäre wohl machbar für Linux, Windows und Mac (wobei unser Mac-support eh noch undefiniert ist... kA, ob irgendwas aktuell auf 'nem Mac läuft über MoltenVK).

Meiner Meinung nach sollten wir allerdings kein Problem irgendeiner IDE in der Anwendung versuchen zu fixen. Das working-directory einfach aus der Gleichung rauszunehmen, schränkt immerhin mehr ein als es Möglichkeiten bietet. Da würde ich eher versuchen über CMake die Binary passend für die problematischen IDEs zu platzieren oder wir schreiben einen Guide, wie man ein working-directory setzt.

Wenn ich wüsste, was für einen Unsinn vscode genau veranstaltet, könnte ich das in CMake machen. Ich verstehe auch nicht wieso Microsoft bei zwei ihrer namensähnlichen IDEs unterschiedliche Defaults verwendet.

Vorausgesetzt man startet die Anwendung aus einem Terminal, ist es halt typisch, dass das working-directory verwendet wird. Jede halbwegs brauchbare IDE kann auch das working-directory setzen und im Endeffekt halt ich den generellen Nutzen bei Usern/Entwicklern für größer, wenn sie ein working-directory zu setzen lernen können als unsere Abstraktion zu verwenden. Denn wenn ich trotzdem einen Pfad relativ (unabsichtlich oder nicht) verwenden würde, wäre ich als Nutzer nur mehr verwirrt, wenn wir das 1.) falsch-korrigieren oder 2.) nicht konsistent verwenden.

Zu dem Zeitpunkt, zu dem der relative Pfad gesetzt wurde (im Code) ist ja nichts über den Ort des Invokierens bekannt. Wenn man eh davon ausgeht, dass eh immer aus dem Build Ordner gestartet wird, kann man diesen ja auch direkt setzen und hat dann immer das gleiche Ergebnis. Ich denke dabei halt an die Unterscheidung: Anwendungen, die in erster Linie dazu da ist, Dateimanipulationen durchzuführen (-> Working Directory sinnvoll) und Anwendungen, die statische Daten laden sollen (-> fester Pfad sinnvoll). So wie ich es momentan gedacht hätte, wäre es ja auch absolut optional und auch sichtbar für den Entwickler, da alles in der main.

Zusätzlich ist das working-directory auch bei jedem graphischen Explorer auch automatisch identisch zum Anwendungsverzeichnis, wenn ich es nicht vom Terminal sondern per Maus starten möchte. Da sehe ich auch kein Problem. Verknüpfungen usw. erlauben auch das setzen von working-directory.

jo, da sehe ich auch kein Problem

Meiner Meinung nach sollten wir allerdings kein Problem irgendeiner IDE in der Anwendung versuchen zu fixen. Das working-directory einfach aus der Gleichung rauszunehmen, schränkt immerhin mehr ein als es Möglichkeiten bietet. Da würde ich eher versuchen über CMake die Binary passend für die problematischen IDEs zu platzieren oder wir schreiben einen Guide, wie man ein working-directory setzt.

naja, es verhindert ja die Nutzung des Working Directorys nicht - Man könnte damit halt nur bestimmte (statische) Sachen relativ zum Binary Dir definieren. Also keine Regression, nur Zusatz-feature ^^ Ich habe das ganze aber auch nicht in erster Linie als IDE-Fix gedacht. Würde offiziell sowieso kein VSCode unterstützen - Ich bin zwar Fan davon, weil so customizable - aber dementsprechend halt auch viel Gefrickel möglich und nicht garantiert, dass es in naher Zukunft auf gleiche Weise läuft.

added 🙏 Review label

added 1 commit

• 7b3fe284 - [#83 (closed)] vscode - Y U not use spaces?!

Compare with previous version

added 1 commit

• 17b8ab61 - [#83 (closed)] remove boost, using std::filesystem

Compare with previous version

closed