Hallo, ich möchte die aktuellen Versionen von GtkWave und iVerilog für Windows haben. Die gibt es leider nicht als Download, aber das geht wohl indem man MSYS2 verwendet. Das hab ich runtergeladen, installiert und auch die Updates gezogen. Soweit so gut. Ich glaube aber, dass beim Ziehen der Packages für GtkWave und iVerilog was schief ging, bin aber nicht sicher, da ich mit dem MSYS2-Konzept (eigentlich ist das ja Linux-Konzept, oder?) noch nicht vertraut bin - wahrscheinlich gehe ich von falschen Erwartungen aus: Ich habe die MinGW64-Konsole geöffnet und die MSYS2-Packages für GtkWave und iVerilog gezogen. Als purer Anfänger war meine Erwartungshaltung, dass damit eigentlich nur die Informationen bzgl. Sourcecodequellen und Build-Einstellungen heruntergeladen werden und ich dann (geschickterweise) in einem Buildverzeichnis meiner Wahl ein 'make xxx' aufrufe und in diesem Verzeichnis dann das Windows-Executable auftaucht. Soviel zur Theorie eines Windows-Users... 8D Die Praxis sah dann so aus, dass im (vorher leeren) MinGW64\bin-Unterverzeichnis schon die ganzen EXE-Dateien etc. aufgetaucht sind, für beide Programme. Damit ist zwar das Ziel erreicht, aber ich versteh den Weg nicht und das gefällt mir nicht. Wenn mit dem Laden der Pakete schon die fertigen Programme rausfallen, kann ich erstmal damit leben, momentan will ich ja nur aktuelle Versionen haben und selbst nix ändern. Dass die wohl alle absichtlich im MinGW64-Unterverzeichnis landen hatte ich beim (zweiten) genaueren Durchlesen der entsprechenden Paketseiten bemerkt - runterscrollen und alles lesen kann hilfreich sein. Was mich nun interessieren würde ist zum einen, ob es einen Weg gibt für jedes Paket ein separates Verzeichnis zu haben. Wenn nicht, dann muss man eben nach jedem Paketdownload manuell verschieben - unschön, aber machbar. Wie bereits erwähnt dachte ich, dass man aus einem Verzeichnis seiner Wahl heraus ein 'make' o.ä. aufruft und in diesem Verzeichnis dann die Programme erstellt werden. In der Konsole gibt's aber wohl keine Kommandos für Verzeichnisse/Dateien, bspw. 'ls' oder 'dir' spucken genau gar nix aus. Aber das sollte doch eigentlich gehen, oder? Was fehlt mir da? Zum anderen wäre natürlich interessant zu wissen, ob bzw. wie denn meine ursprüngliche Annahme umgesetzt werden kann: gibt es die Möglichkeit, für ein Paket die Sourcecodes und Compiler-/Linkereinstellungen runterzuladen? Oder geht man da einfach den Weg über bspw. GitHub und Co und lädt sich das Projekt von dort herunter? Und zu guter Letzt noch eine Frage bzgl. der Berechtigungen: als ich auf MSYS2 als mögliche Lösung gestossen bin hatte ich auch eine Seite gefunden, auf der davor gewarnt wurde MSYS2 mit root/Admin-Berechtigungen zu verwenden, da in diesem Fall wohl bei einem Build ein anderes Verzeichnis verwendet wird als im Falle eines normalen Users. Leider finde ich die Seite nicht mehr :( Ich bin nicht sicher ob die Warnung nur im Linux-Umfeld von Bedeutung ist oder gerade bei Verwendung unter Windows. Vielleicht hat jemand weitere Infos hierzu? Grüße und schönen Abend.
mingw ist kein Linux, mingw ist auch kein Betriebsystem, mingw ist im wesentlichen ein gcc unter Windows. Mehr als, das, was es ist, ist es nicht. Wenn du lieber mit einem echten Linux arbeiten willst, installier dir eins in einer virtuellen Maschine, oder nimm WSL. Oliver
Hallo Oliver, es geht ja nicht darum Linux zu verwenden, sondern eine aktuelle Version der beiden Programme unter Windows zu haben. Was die drei genannten Fragen angeht bin ich ein Stück weiter gekommen: ls/dir funktionieren schon, sie zeigen eben nix an, wenn im entsprechenden Verzeichnis auch nix drin ist :) Das Startverzeichnis ist das angelegte Home-Verzeichnis, da ist erstmal nix drin... Bzgl. dem eigenen Verzeichnis für ein Paket hat pacman einen -root Schalter, mit dem man wohl ein anderes Rootverzeichnis spezifizieren kann, den werde ich mal genauer unter die Lupe nehmen. Grüße
Ralf schrieb: > es geht ja nicht darum Linux zu verwenden, Du bekommst per pacman fertig kompilierte Dateien und Libs. Wenn du dir selber Pakete aus den Sourcen bauen willst, dann liefert dir msys2 die toolchain und eine Build-Umhebung dafür. Das ist der ureigentliche Zweck von mingw, dafür wurde das mal erfunden. Eine linuxartige Paketverwaltung auf Sourcecodeebene gibt es da nicht. Und trotzdem ist es manchmal (sehr viel) einfacher, Linux-Anwendungen für Windows unter Linux zu bauen. Alles, was mit „configure“ losgeht, macht unter Windows selten Spaß. Oliver
Irgendwie verstehe ich das Problem nicht. Du willst die Programme haben und hast sie dir per MSYS installiert. Offenbar hattest du gedacht, dass das nur der Quellcode sei und du ihn noch compilieren müsstest, was aber nicht der Fall ist - umso besser. Ist damit dein Problem nicht gelöst? Warum müssen die Programme unbedingt in separaten Verzeichnissen liegen? Bei MSYS ist die Verzeichnisstruktur so, wie unter Unix-artigen Systemen üblich. Die ist grundlegend anders als die unter Windows übliche.
Rolf M. schrieb: > Irgendwie verstehe ich das Problem nicht. Du willst die Programme > haben > und hast sie dir per MSYS installiert. Offenbar hattest du gedacht, dass > das nur der Quellcode sei und du ihn noch compilieren müsstest, was aber > nicht der Fall ist - umso besser. Ist damit dein Problem nicht gelöst? > Warum müssen die Programme unbedingt in separaten Verzeichnissen liegen? > Bei MSYS ist die Verzeichnisstruktur so, wie unter Unix-artigen Systemen > üblich. Die ist grundlegend anders als die unter Windows übliche. Ja, das ist sehr gewöhnungsbedürftig.
@Rolf M: > Irgendwie verstehe ich das Problem nicht. Du willst die Programme haben > und hast sie dir per MSYS installiert. Offenbar hattest du gedacht, dass > das nur der Quellcode sei und du ihn noch compilieren müsstest, was aber > nicht der Fall ist - umso besser. Ist damit dein Problem nicht gelöst? Soweit korrekt, das Ziel an sich ist ja theoretisch schon erreicht - sofern die Pakete jeweils aktuell sind. Ich weiß ja nicht wann die Pakete aktualisiert werden. Zumindest kann ich aber ziemlich sicher sein, dass ich jetzt was aktuelleres habe als das, was ich im Web zum runterladen gefunden habe. > Warum müssen die Programme unbedingt in separaten Verzeichnissen liegen? > Bei MSYS ist die Verzeichnisstruktur so, wie unter Unix-artigen Systemen > üblich. Die ist grundlegend anders als die unter Windows übliche. Dass das unter unixoiden Systemen so üblich ist und auch funktioniert stelle ich auch nicht infrage. Unter Windows sieht das leider etwas anders aus - dort macht es m.E. eben Sinn, dass jedes Programm sein eigenes Verzeichnis hat. Es hat seinen Grund warum dort im Ordner 'C:\Programme' & Co. jeweils ein Unterverzeichnis existiert, wenn man alle Programme direkt in ein Verzeichnis ballern würde funktioniert das System nicht mehr. Ich kenne die grundlegende Struktur der unixoiden System noch nicht, ich unterstelle jetzt mal, dass ein Programm i.d.R. genau eine ausführbare Datei ist. Dann kannst du alles in einem Verzeichnis haben. Bei Windows-Programmen mit zig DLLs, etc. und sonstigem Kram würde das eben in die Hose gehen. Und daher eben der Wunsch, dass die beiden Pakete nicht in 'MinGW64\bin' landet (denn da gehört es m.E. als Windows-Programm nicht hin, das ist ja soweit ich verstanden habe das Verzeichnis des MinGW64-Compilers), sondern eben in einem separaten Ausgabeverzeichnis. Grüße
Ralf schrieb: > Ich kenne die grundlegende Struktur der unixoiden System noch nicht, ich > unterstelle jetzt mal, dass ein Programm i.d.R. genau eine ausführbare > Datei ist. Nein, ein Programm besteht meistens ebenfalls aus mehreren (ggf. vielen) Dateien. Die werden aber nicht nach Programm sortiert abgelegt, sondern nach Funktion der Datei. > Bei Windows-Programmen mit zig DLLs, etc. und sonstigem Kram würde das > eben in die Hose gehen. Sowas gibt es auch. Die ausführbaren Dateien landen in bin, die Bibliotheken in lib, u.s.w. > Und daher eben der Wunsch, dass die beiden Pakete nicht in 'MinGW64\bin' > landet (denn da gehört es m.E. als Windows-Programm nicht hin, das ist ja > soweit ich verstanden habe das Verzeichnis des MinGW64-Compilers), > sondern eben in einem separaten Ausgabeverzeichnis. Das ist das Verzeichnis, in dem alle ausführbaren Dateien landen. Dadurch kann man die alle von der Konsole aus recht leicht erreichen, wenn dieses eine Verzeichnis im PATH ist. Bei der Windows-Methode müsste man für jedes Programm einen eigenen Verzeichnis-Eintrag in PATH haben. Der Rest des Pakets landet in den Verzeichnissen, in die er nach dem Unix-Prinzip gehört.
Wie gesagt, msys2/mingw ist kein Betriebssystem. Es stellt aber ein Umgebung bereit, die linuxoide Programme brauchen. Umgebung heisst, angepasste Pfade und all die zur Laufzeit benötigten libs. Das packt dafür alle Programme und libs mehr oder weniger plump in ein Verzeichnis. Wenn dein GTKWave statisch gelinkt ist, brauchst du msys2 nicht, um das auszuführen. Ist es dynamisch gelinkt, läuft das nur im msys2-Environment, und dann kann es auch gleich dort im bin-Verzeichnis bleiben. Oliver
Ralf schrieb: > Soweit korrekt, das Ziel an sich ist ja theoretisch schon erreicht - > sofern die Pakete jeweils aktuell sind. Ich weiß ja nicht wann die > Pakete aktualisiert werden. Zumindest kann ich aber ziemlich sicher > sein, dass ich jetzt was aktuelleres habe als das, was ich im Web zum > runterladen gefunden habe. Du hast durch die MSYS2 Pakete folgende Vorteile: 1. Du sparst dir die Arbeit. 2. Du sparst dir die Arbeit Code eventuell anzupassen, falls er nicht compiliert. Das machen die MSYS2 Leute bereits für dich. 3. Du sparst dir die Arbeit die Pakete aktuell zu halten. MSYS2 bietet ne Updatefunktion, womit du die Pakete einfach updaten kannst, sobald die MSYS2 Leute ein neues Paket bereit gestellt haben. Wie lange das dauert, dürfte Paketabhängig sein, das kann ich dir nicht genau sagen. 4. Auch wenn MSYS2 seine eigene Verzeichnisstruktur hat, kannst du davon ausgehen, dass ein einzelnes Paket wieder sauber deinstalliert wird, wenn du die Deinstallation über die MSYS2 Paketverwaltung durchführst. Selber bauen ist sinnvoll, wenn: 1. Man wissen will, wie es geht. 2. Man den Code vorher noch anpassen will. 3. Das Programm auf einen bestimmten Prozessor optimieren will. 4. Man selber bei dem MSYS2 Projekt mitmachen will. > Dass das unter unixoiden Systemen so üblich ist und auch funktioniert > stelle ich auch nicht infrage. Unter Windows sieht das leider etwas > anders aus - dort macht es m.E. eben Sinn, dass jedes Programm sein > eigenes Verzeichnis hat. Das macht nur dann Sinn, wenn Hersteller A und Hersteller B nicht voneinander wissen, wie sie ihre Dateien untereinander benennen sollen, damit sie nicht in Konflikt geraten. Ansonsten aber wäre auch da ein einheitlicher Ordner von Vorteil, weil du so auch nur einen Eintrag in der PATH Variable brauchst. Wenn du Programm A und B von der Eingabeaufforderung aus starten willst, dann musst du dem Programm mitteilen, wo es liegt bzw. in dessen Verzeichnis wechseln. Hast du für A und B zwei verschiedene Ordner, dann musst du die PATH Variable um zwei Ordner erweitern. Machst du das bei n Programmen, dann wird deine PATH Variable schnell zugekleistert. Gut möglich, dass es da sogar ein Zeichenlimit gibt. Wenn du A und B nur in einem Verzeichnis hast, so wie bei MSYS, dann brauchst du nur einen Eintrag in PATH und bei MSYS2 guckt man schon danach, dass die Dateien sich nicht ins Gehege kommen, also auch notfalls umbenannt werden. > Es hat seinen Grund warum dort im Ordner > 'C:\Programme' & Co. jeweils ein Unterverzeichnis existiert, wenn man > alle Programme direkt in ein Verzeichnis ballern würde funktioniert das > System nicht mehr. Ich kenne die grundlegende Struktur der unixoiden > System noch nicht, ich unterstelle jetzt mal, dass ein Programm i.d.R. > genau eine ausführbare Datei ist. Dann kannst du alles in einem > Verzeichnis haben. Bei Windows-Programmen mit zig DLLs, etc. und > sonstigem Kram würde das eben in die Hose gehen. Es gibt auch bei Unix Systemen shared Libraries. Die Enden aber nicht auf *.dll, sondern auf *.so > Und daher eben der > Wunsch, dass die beiden Pakete nicht in 'MinGW64\bin' landet (denn da > gehört es m.E. als Windows-Programm nicht hin, das ist ja soweit ich > verstanden habe das Verzeichnis des MinGW64-Compilers), sondern eben in > einem separaten Ausgabeverzeichnis. Wenn das Programm mit ./configure compiliert wird, dann kannst du ein anderes Verzeichnis mit dem --prefix Paramter setzen. Also bspw.: ./configure --prefix=C:\Programme\programm_a\ und für Programm B: ./configure --prefix=C:\Programme\programm_b\ Ob das mit dem Laufwerksbuchstaben und dem Backslash anstatt Slash so klappt, weiß ich allerdings nicht. Ich glaube bei MYSYS2 verwendet man Buchstaben als Verzeichnisname für die Laufwerksbuchstaben, also so: ./configure --prefix=/c/Programme/programm_a/ und für Programm B: ./configure --prefix=/c/Programme/programm_b/ Musst du halt ausprobieren. Aber das wäre so die Vorgehensweise, wenn du das Programm in einem anderen Verzeichnis haben willst. Unter Unix/Linux nutzt man das bspw. wenn man etwas selber compiliert und da nicht im Verzeichnis der Distribution herumpfuschen will. Dann kann man das bspw. nach /opt/programm/ schicken. Ach ja, installieren geht dann über: make install Die Deinstallatioinsroutine wäre make uninstall Aber die funktioiniert nur, wenn dein Quellcodeverzeichnis noch da ist. Wenn du es löschst muss du dich manuell darum kümmern. Bei MSYS2 gibt's dafür entsprechende Deinstallationskripte, die vom Paketsystem benutzt werden und von den MSYS2 Machern zusammengestellt wurde. Mein Tipp: Spare dir die Arbeit und nimm die MSYS2 Variante und lerne damit zu leben, wie dort Programme in eine gemeinsame Verzeichnisstruktur eingepflegt werden. Damit hast du dann wesentlich weniger Aufwand.
Nano schrieb: > ./configure --prefix=/c/Programme/programm_b/ Noch etwas zu vergessen. Programme ist natürlich ein lokalisierter Verzeichnisname. Das musst du also auch noch beachten.
Hallo zusammen, sorry für die späte Rückmeldung. @Rolf M: >> Bei Windows-Programmen mit zig DLLs, etc. und sonstigem Kram würde das >> eben in die Hose gehen. > Sowas gibt es auch. Die ausführbaren Dateien landen in bin, die > Bibliotheken in lib, u.s.w. Siehe Anmerkung unten. >> Und daher eben der Wunsch, dass die beiden Pakete nicht in 'MinGW64\bin' >> landet (denn da gehört es m.E. als Windows-Programm nicht hin, das ist ja >> soweit ich verstanden habe das Verzeichnis des MinGW64-Compilers), >> sondern eben in einem separaten Ausgabeverzeichnis. > Das ist das Verzeichnis, in dem alle ausführbaren Dateien landen. > Dadurch kann man die alle von der Konsole aus recht leicht erreichen, > wenn dieses eine Verzeichnis im PATH ist. Bei der Windows-Methode müsste > man für jedes Programm einen eigenen Verzeichnis-Eintrag in PATH haben. > Der Rest des Pakets landet in den Verzeichnissen, in die er nach dem > Unix-Prinzip gehört. Seh ich alles ein und das ist ja auch praktisch - wenn man unter UNIX & Co. arbeitet. Nochmal: unter Windows arbeitet man anders. Lassen wir außen vor welches Konzept besser ist, darum geht es nicht. Irgendwie ist das grad so oder so interpretierbar. Getrennte Verzeichnisse für die Executables, Bibliotheken, etc. ist klar. Unter UNIX & Co. gibt's das jeweils genau einmal. Schön. Unter Windows gibt's das auch - aber eben getrennt nach Programm, d.h. jedes Programm in einem eigenen Verzeichnis und dort dann \bin, \lib, etc. Das hab ich nahezu bei jedem Programm, welches ursprünglich aus der UNIX-Welt kommt und für Windows portiert wurde. Ist ja auch okay so, wie das dann in den Unterverzeichnissen aufgebaut ist, ist mir dann wurscht (eigentlich nicht, ehrlich gesagt finde ich das mit \bin, \lib etc. im Unterverzeichnis gut). Ich hab grad mal geguckt, die GCCs, die aufgrund paralleler Verwendung von IDEs für verschiedene Microcontroller auf meinem System rumlümmeln sind nicht in irgendeinem gemeinsamen Verzeichnis, die sind im Unterverzeichnis der jeweiligen IDE (mit der genannten Ordnerstruktur unterhalb). InkScape: das gleiche. Auch die beiden Programme um die es mir geht (iVerilog und GtkWave) machen das im Windows-Port so. Du siehst, die pappen sich nicht in ein gemeinsames Standardverzeichnis - nein, die möchten sich gerne in ein Unterverzeichnis pappen lassen, dass man wählen darf und sie legen dort dann die wiederum von dir genannte Struktur an. Das ist unter Windows gut so. Wenn das nicht so wäre, warum glaubst du machen die ganzen Windows-Ports das so und installieren sich nicht alle per se in "C:\bin", "C:\lib", etc? Du möchtest mich von einem Konzept überzeugen welches unter Windows nicht gibt und dort auch nicht dauerhaft (gut) funktionieren kann. Es ist bestimmt gut gemeint, aber es geht an meinem Ziel vorbei. @Oliver S: > Wie gesagt, msys2/mingw ist kein Betriebssystem. Es stellt aber ein > Umgebung bereit, die linuxoide Programme brauchen. Umgebung heisst, > angepasste Pfade und all die zur Laufzeit benötigten libs. Das packt > dafür alle Programme und libs mehr oder weniger plump in ein > Verzeichnis. > Wenn dein GTKWave statisch gelinkt ist, brauchst du msys2 nicht, um das > auszuführen. Ist es dynamisch gelinkt, läuft das nur im > msys2-Environment, und dann kann es auch gleich dort im bin-Verzeichnis > bleiben. Jetzt wird es ein bisschen klarer, danke. Das muss ich als Frage direkt mal an Rolf M. weitergeben: kann es sein, dass du davon ausgegangen bist, dass ich die beiden Programme innerhalb MSYS2 betreiben möchte? Wenn ja, dann haben wir aneinander vorbei geredet. Da auch die Windows-Ports die ich bereits habe (egal ob iVerilog, GtkWave, InkScape oder was auch immer) jeweils aus ihren eigenen Verzeichnissen heraus laufen (und das bevor ich MSYS2 installiert hatte) sind die wohl statisch gelinkt und das hätte ich auch gerne weiter so. Ich wollte MSYS2 wirklich nur dazu verwenden, den Quellcode für Windows zu compilieren ohne eine zusätzliche Umgebung für die Ausführung zu benötigen. Wenn das die fertigen Pakete nicht bereits ausspucken können, dann mach ich's auch gerne über Quellcode & Compilieren, wenn mich da jemand an die Hand nehmen mag. @Nano: > Du hast durch die MSYS2 Pakete folgende Vorteile: > ... > Selber bauen ist sinnvoll, wenn: > ... Das selber bauen ist durchaus reizvoll, ich denke das ist auch flexibler (wenn man weiß wie's geht und was man tut, da bin ich eben noch nicht). > Das macht nur dann Sinn, wenn Hersteller A und Hersteller B nicht > voneinander wissen, wie sie ihre Dateien untereinander benennen sollen, > damit sie nicht in Konflikt geraten. Unter Windows ist das noch schlimmer, die wissen da nicht nur nix von, das ist denen auch völlig wurscht. Deswegen ist es ja unter Windows so wie es ist. > Ansonsten aber wäre auch da ein einheitlicher Ordner von Vorteil, weil > du so auch nur einen Eintrag in der PATH Variable brauchst. Ja, aber das ist ne Philosophieeinstellung, UNIX/LINUX so und Windows eben so. Das wirst du aus Windows auch nicht mehr rausgeätzt bekommen. > Wenn du Programm A und B von der Eingabeaufforderung aus starten willst, > dann musst du dem Programm mitteilen, wo es liegt bzw. in dessen > Verzeichnis wechseln. > Hast du für A und B zwei verschiedene Ordner, dann musst du die PATH > Variable um zwei Ordner erweitern. Machst du das bei n Programmen, dann > wird deine PATH Variable schnell zugekleistert. Gut möglich, dass es da > sogar ein Zeichenlimit gibt. > Wenn du A und B nur in einem Verzeichnis hast, so wie bei MSYS, dann > brauchst du nur einen Eintrag in PATH und bei MSYS2 guckt man schon > danach, dass die Dateien sich nicht ins Gehege kommen, also auch > notfalls umbenannt werden. Windows-User die auf dieser Ebene arbeiten sind diesen Schmerz gewöhnt :D An ein potentielles Zeichenlimit bin ich bis dato nicht gekommen und ggw. hält sich die Länge dem Gefühl nach in Grenzen. > Es gibt auch bei Unix Systemen shared Libraries.Die Enden aber nicht auf *.dll, sondern auf *.so Ah, okay. Vermutlich haben die saubere Namen, also exakte Version angegeben? Dann funktioniert das. Unter Windows hat man leider zwei Probleme: keine sauberen Namen und von einer Version zur nächsten nicht unbedingt kompatibel. Letzteres mag unter Linux & Co vermutlich auch vorkommen. Unter Windows ist das leider tödlich, ein Programm bei dem gepennt wurde und zack läuft mindestens das halbe System nicht mehr... > Wenn das Programm mit ./configure compiliert wird, dann kannst du ein > anderes Verzeichnis mit dem --prefix Paramter setzen. > ... > Musst du halt ausprobieren. > Aber das wäre so die Vorgehensweise, wenn du das Programm in einem > anderen Verzeichnis haben willst. Okay, danke. Das wäre ja aber dann kein Paket, sondern Quellcode compilieren, richtig? Ist das dann automatisch die statisch gelinkte Variante oder braucht's da auch noch eine Option dafür? > Unter Unix/Linux nutzt man das bspw. wenn man etwas selber compiliert > und da nicht im Verzeichnis der Distribution herumpfuschen will. > Dann kann man das bspw. nach /opt/programm/ schicken. Das geht schon in die Richtung die ich vorhatte. Ich würde dann nämlich genau auf C:\Programme u.ä. verzichten wollen und das analog in opt/program_a, etc. ausgeben. Unter anderem deswegen weil Windows beispielsweise mitunter paranoid reagiert wenn der User in den Systemverzeichnissen werkelt. Bzgl. der Prefix-Einstellung entspricht dann '/opt/program_a' dem Verzeichnis C:/msys64/opt, wäre das so korrekt? Ein führender Slash ist unter Linux das root-Verzeichnis und in MSYS2 entspricht dies dem Installationsverzeichnis von MSYS2 (in meinem Fall C:/msys2). > Ach ja, installieren geht dann über: > make install Mmmmh, ist das wirklich eine Installation oder das Compilieren? Installation im Windows-Kontext bedeutet, dass das Programm irgendwo reinkopiert wird und ggf. in der Registry rumgewerkelt wird. Genau deswegen gefallen mir die Linux-Programme so, die machen soweit ich weiß genau das nicht. Einfach entpacken (wenn es das Programm als Download gab) und ausführen. > Die Deinstallatioinsroutine wäre make uninstall Das bräuchte ich ja nur in der MSYS-Umgebung (oder allgemein Linux). > Mein Tipp: > Spare dir die Arbeit und nimm die MSYS2 Variante und lerne damit zu > leben, wie dort Programme in eine gemeinsame Verzeichnisstruktur > eingepflegt werden. > Damit hast du dann wesentlich weniger Aufwand. Mja, wart mal... mir geht da grad n Kompromiss durch'n Kopp mit dem ich evtl. auch leben kann und der gefühlt beides vereint. Also wie man ein Programm separat, statisch gelinkt (also ohne MSYS2 lauffähig) und in einem eigenen Verzeichnis erzeugt würde mich interessieren (das ist das Eingangsszenario). Was ich mir darüber hinaus vorstellen kann wäre ein Verzeichnis 'C:/WindowsPorts' o.ä. in dem die genannte Verzeichnisstruktur existiert und die Programme UNIX/LINUX-like abgelegt sind. Wenn das auch statisch gelinkt so funktioniert kann ich damit auch ganz gut leben denke ich. Und wenn das direkt das "C:\msys64\mingw64" sein kann, dann ist es mir auch recht. Würde das gehen? Grüße
Ralf schrieb: > Was mich nun interessieren würde ist zum einen, ob es einen Weg gibt für > jedes Paket ein separates Verzeichnis zu haben. Wenn nicht, dann muss > man eben nach jedem Paketdownload manuell verschieben - unschön, aber > machbar. Wie bereits erwähnt dachte ich, dass man aus einem Verzeichnis > seiner Wahl heraus ein 'make' o.ä. aufruft und in diesem Verzeichnis > dann die Programme erstellt werden. Die Pakete liegen in /var/cache/pacman/pkg und sind tar (zip) Files. Die kannst du auch woanders hin auspacken, soferne die Abhängigkeiten gefunden werden. Auch die Windows "native" Programme hängen von einer Vielzahl von Msys2 DLLs ab, ohne die sie nicht laufen. Ansonsten musst du die Sourcen selber compilieren. Das geht dank der vorbereiteten Patches für die Pakete einfach, ist aber zeitaufwendig. Details findest du hier: https://www.msys2.org/wiki/Creating-Packages/ Wenn du nicht viel Erfahrung und viel Geduld hast kannst du selber Compilieren vergessen. Die meisten Programme compilieren unter Msys nur mit vielen Patches, die nackten (github) Source Files sind nicht ausreichend. Die sind ja meist nicht für Windows geschrieben, und das Ergebnis ist entsprechend. Wenn du selber unter Windows entwickeln möchtest, dann nimm Visual Studio. Msys2 ist nur für Hardcore Programmierer, die ihre Grenzen kennenlernen wollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.