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.
