3. Wie organisiert ihr eure C++ Projekte

Wie organisiert ihr eure C++ Projekte

  • T

    dot schrieb:

    TyRoXx schrieb:

    tntnet schrieb:

    Ich kenne nur die Dll-Hölle aus alten Windows-Tagen, wo alle Dlls unter C:\windows installiert wurden unabhängig davon, ob da bereits eine ältere oder gar neuere Version vorhanden ist. Ist das inzwischen gelöst?

    Natürlich nicht.

    Natürlich gibts unter Windows eine Lösung dafür. Unter Linux wäre mir eine solche dagegen nicht bekannt. Wie ist das dort wenn ich z.B. mehr als einen OpenGL Driver haben möchte? Macht jedes Mal wieder aufs Neue Spaß...

    Interessant. Das kannte ich nicht. Wobei, wenn ich das richtig verstehe ist das unter Linux einfach lösbar. Also zumindest der Fall, dass 2 Applikationen unterschiedliche shared libraries aber mit gleichen Namen benötigen. Da kann man natürlich mit LD_LIBRARY_PATH einstellen, wo die libs zu suchen sind. Aber das sind Spezialfälle. In aller Regel macht das der Paketmanager.

    Und warum braucht man mehr als einen OpenGL-Driver? Ich kenne das Problem nicht. Eigentlich kommt niemand plötzlich auf die Idee: Hey - ich brauche mal einen OpenGL-Driver. Eher denkt der Mensch: Hey - ich hätte gerne mal ein Programm, welches meine Termine verwaltet. Oder ich würde gerne mal ein neues Spiel ausprobieren. Da geht man unter Linux in die Softwareverwaltung und installiert sich das benötigte Programm. Dass da eventuell noch ein OpenGL-Driver oder was auch immer mit installiert wird, interessiert nicht wirklich. Hauptsache das Programm funktioniert.

    dot schrieb:

    tntnet schrieb:

    Da war es doch so, dass Dlls einfach in das Windows-Verzeichnis kopiert wurden, da es keinen Paketmanager gab.

    Das wurde und wird so gemacht; von Leuten die keine Ahnung haben. Im Windows Verzeichnis haben nur Systemkomponenten was zu suchen. Das war schon immer so und ist weiterhin so...

    Wenn ich doch unter Windows ein Programm installieren möchte, dann starte ich das Setup-Programm der jeweiligen Software. Wenn das von solchen Leuten geschrieben wurd, die eben keine Ahnung haben, dann passiert das eben. Und das ohne dass der Anwender, bzw. Administrator, der das Programm installiert wirklich Einfluss darauf hat.

    Mit einem Paketmanager starte ich nicht das Setup-Programm der Anwendung sondern eben den Paketmanager, der für die Kosistenz des Gesamtsystems verantwortlich ist und eben nicht nur für das zu installierende Programm. Der Paketmanager kann erkennen, wenn ein Paket eine Datei enthält, die ein anderes Paket bereits installiert hat. Es verweigert in dem Fall die Installation, da ein anderes Paket damit beschädigt würde.

    Ein schlecht geschriebenes Setup-Programm würde die andere Software einfach kaputt machen.

    Und weiterhin möchte ich kein Flamewar führen. Ich kenne nur die Vorteile der Softwareverwaltung unter Linux und habe von den modernen Windows-Versionen nicht wirklich Ahnung. Ich kenne nur die Nachteile der klassischen Softwareverwaltung (also eigentlich nicht exisitierenden) von Windows.

    Ich glaube nicht, dass ein Endanwender so ein side-by-side assembly konfigurieren möchte. Er möchte einfach nur eine Software installieren.

    0
  • T

    Maik82 schrieb:

    Guten Morgen!

    Ok, wenn ich das richtig verstehe kopiert Ihr immer die Versionen direkt in die entsprechenden Systemverzeichnisse und organisiert diese nicht bei Euch im "Projekt-Workspace", unabhängig ob jetzt bei den Windows oder UNIX Nutzern?

    Anfangs hatte ich das auch so gemacht, irgendwann hatte ich dann aber das Gefühl ich "mülle" mir während der Entwicklung immer mehr mein System zu, z. B. da ich viele kleinere externe Libs verwende und diese sich in Version teilweise von denen Unterscheiden, die bereits von anderen Programmen mitgeliefert wurden.

    Das ist aber einfach mein persönlicher Geschmack!

    Guten Morgen

    Um gottes Willen nein. Ich mülle unter UNIX nicht die Systemverzeichnisse voll. Man muss unterscheiden, was man benötigt.

    Wenn ich für meine Software beispielsweise openssl benötige, installiere ich mir die entsprechenden Dev-Pakete über die Softwareverwaltung. Damit steht das systemweit zur Verfügung und der Vorgang ist auf anderen Rechnern nachvollziehbar.

    Eine andere Sache ist, wenn die benötigte Software nicht im Repository verfügbar ist. Dann sollte man sich eben ein Paket bauen oder unter }/usr/local installieren. Und ja - /usr/local ist eine solche Müllhalde. Damit sollte man vorsichtig um gehen. Der Vorteil ist, dass das leeren des Verzeichnisses das System nicht kaputt macht, da dort keine Sachen abgelegt werden dürfen, die für das System notwendig sind.

    Dann gibt es natürlich noch den Fall, dass die Lib ein Bestandteil der aktuell entwickelten Software ist. Dann wird sie gar nicht installiert, sondern da muss das Build-System eben so konfiguriert werden, dass die Sachen eben innerhalb des Projektes gefunden werden.

    0

  • tntnet schrieb:

    Wobei, wenn ich das richtig verstehe ist das unter Linux einfach lösbar. Also zumindest der Fall, dass 2 Applikationen unterschiedliche shared libraries aber mit gleichen Namen benötigen. Da kann man natürlich mit LD_LIBRARY_PATH einstellen, wo die libs zu suchen sind.

    Das kannst du unter Windows auch, mit der PATH Environment Variable; ist aber weder elegant noch ausreichend. Spätestens wenn die selbe Anwendung verschiedene Versionen der selben Library benötigt – z.B. weil deine Anwendung mit einer bestimmten Version eines Compilers kompiliert wurde und dynamisch eine Library linked, die mit einer anderen Version des selben Compilers kompiliert wurde (was dazu führt, dass beide verschiedene Versionen der selben Runtime Library benötigen) geht es ohne richtigen Support für Versionierung Seitens des OS Loaders nicht mehr...

    tntnet schrieb:

    Und warum braucht man mehr als einen OpenGL-Driver? Ich kenne das Problem nicht.

    Nun, ich bin halt im Grafikbereich unterwegs und das ist das Beispiel, das mir regelmäßig Schmerzen bereitet. Eigentlich hat man das Problem aber auf praktisch jedem modernen PC mit einer Intel CPU (die mittlerweile alle eine integrierte GPU haben) und einer zusätzlichen, dedizierten Grafikkarte. In meinem Arbeits PC hab ich mindestens 2, meistens 3 Grafikkarten und die wechseln ständig. Für mein Windows kein Problem, mein Linux kann ich dagagen alle paar Monate neu aufsetzen, weil nix mehr läuft. Liegt vermutlich zum Teil auch an mangelndem Wissen meinerseits, aber ich hab weder Zeit noch Lust, mich immer wieder stundenlang mit der Konfiguration des Systems zu spielen...

    tntnet schrieb:

    Wenn ich doch unter Windows ein Programm installieren möchte, dann starte ich das Setup-Programm der jeweiligen Software. Wenn das von solchen Leuten geschrieben wurd, die eben keine Ahnung haben, dann passiert das eben. Und das ohne dass der Anwender, bzw. Administrator, der das Programm installiert wirklich Einfluss darauf hat.

    Ja, das ist leider so, aber das ist eben nicht eine Insuffizienz von Windows, sondern liegt daran, dass der Großteil der Softwareentwickler keinen Plan hat.

    tntnet schrieb:

    Der Paketmanager kann erkennen, wenn ein Paket eine Datei enthält, die ein anderes Paket bereits installiert hat. Es verweigert in dem Fall die Installation, da ein anderes Paket damit beschädigt würde.

    Um all diese Dinge würde der Windows Installer Service sich ebenfalls kümmern, wenn man ihn richtig benutzen würde. Das Problem ist nur, dass die Leute ihn entweder nicht richtig benutzen oder ihn gleich gar nicht benutzen und lieber selbst was halbgares Basteln, das dann so tolle Dinge tut, wie DLLs nach "System32" "installieren". Genau diesen Leuten verdanken wir auch, dass das Ding immer noch "System32" heißt und vermutlich für immer so heißen wird...

    tntnet schrieb:

    Ich glaube nicht, dass ein Endanwender so ein side-by-side assembly konfigurieren möchte. Er möchte einfach nur eine Software installieren.

    Absolut! Das ist Aufgabe des Softwareentwicklers...leider wissen die meisten nichtmal, dass es sowas gibt...

    0
  • T

    dot schrieb:

    tntnet schrieb:

    Ich glaube nicht, dass ein Endanwender so ein side-by-side assembly konfigurieren möchte. Er möchte einfach nur eine Software installieren.

    Absolut! Das ist Aufgabe des Softwareentwicklers...leider wissen die meisten nichtmal, dass es sowas gibt...

    Die meisten wissen nicht, dass es Softwareentwickler gibt 🤡 ?

    Danke für die Ausführungen. Ich würde dann mal sagen, dein Problem mit OpenGL ist ein Bug in der Distribution. Es ist ein sehr spezielles Problem und daher den Distris vielleicht nicht so bewusst. In aller Regel hat man eine Grafikkarte und die wechselt nicht.

    Das Problem ist also die mangelnde Kenntnis der Entwickler und Administratoren. Ich habe weiterhin den Eindruck, dass es unter Windows ein mehr oder weniger ungelöstes Problem ist. Im Prinzip könnte Windows die Installation von Software verweigern, welches nicht über den Softwareinstaller installiert wird. Aber das geht sicher nicht, weil es zu viel Software gibt, die daran scheitern würde.

    Unter Android gibt es ja den Appstore. Das ist ja im Prinzip das gleiche wie das Paketmanagement der Linux Distributionen. Da gibt es auch wenig Probleme.

    0
  • M

    Ich finde auch Linux deutlich einfacher als Windows, weil man die oft gebrauchten libraries und Programme, vorausgesetzt man findet sie, ganz einfach mit einem simplen Kommandozeilenbefehl installieren und dann direkt verwenden kann.
    Bei Windows muss man erstmal auf die homepages gehen, von Hand herunterladen, dann durch die Installation klicken und manchmal noch die path-Variable setzen, die nach einiger Zeit extrem unuebersichtlich wird. Bei einem Update muss man das gleiche nochmal machen und ausserdem muss man immer aufpassen, ob man die 32- oder 64-bit Version hat, wobei es die meisten Programme und libraries auch nur fuer 32 bit gibt.

    Oft gelegentlich Pfade wie boost oder OpenCL (das leider auch unter linux, kack Grafikkartentreiber) habe ich manuell in die Einstellungen von Code-Blocks fuer alle Projekte eingetragen. Ich erwarte nunmal, dass eine boost-Version fuer alle Projekte reicht.

    0

  • tntnet schrieb:

    Ich würde dann mal sagen, dein Problem mit OpenGL ist ein Bug in der Distribution.

    Nope, es ist ein bekanntes Problem, welches direkt aus der Art und Weise, wie die hier besprochenen Dinge unter so ziemlich jeder Linux Distribution gemanaged werden, folgt... 😉

    0
  • T

    dot schrieb:

    tntnet schrieb:

    Ich würde dann mal sagen, dein Problem mit OpenGL ist ein Bug in der Distribution.

    Nope, es ist ein bekanntes Problem, welches direkt aus der Art und Weise, wie die hier besprochenen Dinge unter so ziemlich jeder Linux Distribution gemanaged werden, folgt... 😉

    Ok. Dann ist es ein Bug in der OpenGL-ABI oder -Implementierung. Es ist nicht spezifisch für die Art und Weise, wie Software unter Linux verwaltet wird. Offensichtlich haben sie falsche Designentscheidungen getroffen.

    Ich habe noch immer den Eindruck, dass die Linux-Paketverwaltung etwas ist, was in Windows einfach fehlt.

    Wenn ich unter C:\Windows\System32 beispielsweise eine Datei msdsplxx.dll finde, habe ich praktisch keine Chance raus zu finden, ob die Datei systemimmanent ist oder von einem Trojaner dort platziert wurde. Unter einer anständigen Paketverwaltung, wie ich sie unter Linux vor finde, kann ich zu jeder Datei unter /usr/lib fragen, zu welchem Paket sie gehört und sogar prüfen, ob sie manipuliert wurde. Ich kann das Paket auch restlos deinstallieren, aber nur, wenn kein anderes Paket davon abhängt.

    Genau solche Dinge habe ich unter Windows vermisst und meine Frage ist noch immer, ob es so was unter Windows inzwischen gibt?

    Eine andere Sache sind Sicherheitsupdates von Paketen. Unter Windows bringt jedes Paket seinen eigenen Mechanismus mit. Habe ich 10 Softwarepakete installiert, laufen 10 Hintergrundtasks, die prüfen, ob die Software auf dem neuesten Stand ist.

    Unter Linux habe ich genau eine Instanz, welches das Gesamtsystem inklusive der installierten Pakete aktualisieren kann. Ich musste unter Linux nicht die bash explizit updaten, sondern das wurde über den selben Mechanismus aktualisert, wie openssl ein paar Wochen vorher oder die vielen kleinen anderen Updates, die so nach und nach eingespielt werden (womit ich so nebenbei erwähnt habe, dass Linux sicher nicht fehlerfrei und perfekt ist 😉 ).

    Gibt es unter Windows so was? Und wenn ja, warum wird das nicht verwendet? Oder ist meine Beobachtung falsch?

    0
  • C

    tntnet schrieb:

    ob es so was unter Windows inzwischen gibt?

    Ich weiß von einem Paketmanager für Windows.
    Ob der aber alle deine Wünsche erfüllt, kann ich nicht sagen - hab' ihn mir noch nicht näher angesehen.

    0
  • T

    Caligulaminus schrieb:

    tntnet schrieb:

    ob es so was unter Windows inzwischen gibt?

    Ich weiß von einem Paketmanager für Windows.
    Ob der aber alle deine Wünsche erfüllt, kann ich nicht sagen - hab' ihn mir noch nicht näher angesehen.

    Er erfüllt sicher nicht meine Wünsche. Ich arbeite unter Linux und der läuft nicht damit 😃 .

    Nein im Ernst: es geht nicht darum, meine Wünsche zu erfüllen. Es geht darum, was man von einem Betriebssystem erwarten kann. Und jedes Betriebssystem ausser Windows hat eine Softwareverwaltung. Dass man das nachrüsten kann, ist kein Argument. Und ich bezweifle, dass ein solcher Paketmanager das erfüllen kann. Die Software für Windows wird ja nicht in dem Paketformat dieses Paketmanagers zur Verfügung gestellt sondern der Umfang muss von dem Paketmanager irgendwie trickreich ermittelt werden. Und das kann nicht zuverlässig funktionieren.

    0
  • A

    Für gewöhnlich werden natürlich auch die Windows-Anwendungen für die Windows-Packetmanager speziell packetiert. Warum sollte das nicht der Fall sein?

    ZeroInstall für Windows macht das jedenfalls. Keine Konflikte mit Nicht-ZeroInstall-Anwendungen, weil ZeroInstall alle Anwendungen in einem eigenen Verzeichnis installiert und verwaltet... unabhängig vom restlichen System. Nichts mit Setup.exe oder MSI.

    ZeroInstall für Linux gibts auch. Habe ich aber unter Linux nicht ausprobiert. dürfte aber das gleiche machen. Also ein anderer Packetmanager, als der Standard-Distri-Manager.

    Eigentlich verstehe ich das Problem nicht, das es unter Windows geben soll? Keiner kann mir sagen, das man eine Linux-Distri nicht kaputt installieren kann. Wer kann es denn verhindern, das unter einem Linux etwas nicht da landet, wo es nicht landen soll? Immerhin braucht man ja Root-Rechte?

    Das zufällig der Anwender nur den einen mitgelieferten Packetmanager nutzt, ist "Glück". Keine Garantie, das auf einmal mit Rootrechten was anderes gemacht werden kann.

    Übrigens, FreeBSD ist ein Unix... mehr Unix als jedes Linux. Und komischerweise gibt es in der FreeBSD-Welt genau die Probleme, das man eine Lib-Hell hat. Man kann nur immer eine Lib haben. Und wehe jemand will was anderes installieren, wo die Lib nicht passt.

    Lösung? Da haben dann ein paar schlaue Leute PC-BSD raus gebracht, das genau nach dem Windows-Prinzip arbeitet! 😃 Die haben die PBI enwickelt. PBIs sind im Prinzip MSI-Dateien. Also ein Installer-Archiv, das alle Libs mitbringt. Sprich jede Anwendung bringt seine eigenen Libs mit. Weil eben das packen in eine /usr/lib (oder wie auch immer) zu Konflickten führt.

    Ist schon der Hammer, das gerade Windows mit seinen Setup.exe und MSI ein Vorbild für Free-BSD bzw. PC-BSD ist. Die FreeBSD Community kommt mir sowieso immer etwas offener vor für Konzepte des Klassenfeind.

    0
  • T

    http://www.korrekturen.de/beliebte_fehler/packet.shtml

    0
  • ?

    Prinzipiell vergleicht man hier natürlich "zentrale Softwareverwaltung" vs "dezentrale Softwareverwaltung". Was es eigentlich schon müßig macht darüber weiter zu diskutieren. Aber trotzdem möchte ich noch meine Erfahrung mitteilen:

    Also ich sehe eigentlich nicht die Erlösung in Paketmanagern: Bei meinen Linux Erfahrungen mit Debian stable gab es nie alle gewünschte Software über APT. Entweder

    a) gab's die Software gar nicht. Ich musste die Software dann selbst kompilieren. Als Unerfahrener landet die Software dann genauso "irgendwo", genau wie unter Windows. Vermutlich hätte man sie auch nach /usr/local kopieren können, oder sich selbst Pakete erstellen können, aber dies muss man schließlich erstmal wissen!

    oder
    b) der Paketmanager enthielt eine alte Version der gewünschten Software, die schon installiert war. Dies war der GAU für mich, denn ich hatte meine Probleme eine veraltete Version aus dem Paketmanager mit einer aktuellen, selbstkompilierten Version zu friedlicher Koexistenz zu bewegen.

    oder
    c) man versucht sowas wie nen 3D Treiber von AMD zu installieren, der dann für XORG irgendwelche Module baut. Dies kann man dann jede Woche wiederholen, weil der Paketmanager ein XORG Update eingespielt hat und der 3D Treiber natürlich nicht von ihm berücksichtigt wurde. Schlimmer noch: Nach dem Update startet XORG erstmal gar nicht mehr, weil die Konfiguration nun ungültig worden ist.

    Alternativ kann man auch mal versuchen einen anderen Kompiler als die Distribution für die Bibliotheken verwendet hat zu nutzen. Da hat sich für mich - möglicherweise auch wegen Unwissenheit - dann die Hölle aufgetan.

    Im Endeffekt gibt es sicher Für und Wider, aber einen eindeutigen Sieger kann ich nicht ausmachen. Scheint auch viel Gewöhnungssache dabei zu sein.

    0
Anmelden zum Antworten