Einheitliche Buildumgebung in Windows

[lilith2k3]

Hallo liebe Forengemeinde,

ich bin auf der Suche nach einer einheitlichen Lösung für mein Problem:

Grundsätzlich, wenn man unter Windows etwas anderes macht als .NET (soll ja mal vorkommen), so kann man sich ja beispielsweise mit CYGWIN weiterhelfen.

Cygwin beinhaltet den GCC, die Bash, also alles grundlegende Sachen, die schon ganz nett sind für uns Entwickler.

Gut, könnte man sagen, wenn man die Powershell effektiv nutzen kann, wozu dann noch Bash? Aber das lasse ich mal außen vor.

Der große Nachteil an Cygwin ist, dass es eben ein "eigenes Ökosystem" ist. Was ja einerseits nicht schlimm ist, aber, was mich auf der anderen Seite wiederum stört, weil man als Nutzer auf die Cygwin-Pakete angewiesen ist.

Zwar kann ich, wenn ich beispielsweise Ruby 2.0 nutzen will, es auch ganz normal unter Windows installieren und solange es sich im "Path" befindet, kann ich es unter Cygwin nutzen - aber wehe, wenn ich gems bauen will. Dann funktioniert das hinten und vorne nicht. Beispielsweise: »gem install mysql« bricht ständig mit irgendwelchen Compilerfehlern ab. Installiere ich allerdings das "Devkit" von DevKit läuft alles, wie geschmiert. Lustiger Nebeneffekt: Jetzt habe ich neben Cygwin eine zweite "Distribution" auf MSys basierned. Und wieder ein GCC und wieder eine Bash etc. pp.

Richtig spaßig wird es dann, wenn man zusätzlich noch Perl installiert. Aktuell kann man da ja 5.18 benutzen. Cygwin selbst bringt 5.14 mit. Nicht weiter schlimm könnt man denken: Allerdings ist Perl in 32768 Paketen mit als Abhängigkeit definiert. Und man kommt in die von Ubuntu bekannte Dependency-Hell - zumindest in eine light-Variante.

Und der Knaller: Installiert man Git für Windows, erhält man wieder ein komplettes MSys. Damit nicht genug, es bringt auch noch ein Perl mit sich, was in der Version 5.8 vorliegt.

Erwähnte ich schon GHCI? .. besser nicht ...

Mit einem Wort: Das ist ein unbefriedigender Zustand.

Gibt es da keine Alternative?

Was ich mir in etwa vorstelle wäre eine Art Cygwin-Distri, mit einer Handvoll Pakete (Bash und Gnu-Tools, Vi etc.) und entwer die Möglichkeit, aktuelle Versionen von Perl, Python, Ruby, GNU-Haskell, Git etc. pp. eigenständig zu installieren oder noch besser: Die Pakete werden mitgeliefert - Bis die CYGWIN Leute was Portieren ist das Originalpaket schon 5 Versionen weiter :|

Noch besser wäre mir eine "native" Lösung: Quasi Powershell als "Schaltzentrale".

Letzte Lösung: Ich müßte mein System zu Linux migrieren. Nicht, dass ich per se was dagegen hätte -ich fühle mich da eigentlich recht zu hause- aber ich bin ansonsten mit WIN8 zufrieden und möchte nicht unbedingt (wieder) wechseln.

[flashpixx]

Der große Nachteil an Cygwin ist, dass es eben ein "eigenes Ökosystem" ist. Was ja einerseits nicht schlimm ist, aber, was mich auf der anderen Seite wiederum stört, weil man als Nutzer auf die Cygwin-Pakete angewiesen ist.

Dies ist auch der Sinn von Cygwin Cygwin

Es ist eine Kompatibilitätsschicht, die die Unix-API für verschiedene Versionen von Microsoft Windows zur Verfügung stellt, auf deren Basis eine Vielzahl von Programmen aus der Unix-Welt unter Microsoft Windows übersetzt werden können.

[...]

Kern von Cygwin ist die so genannte Cygwin-DLL (cygwin1.dll), eine Dynamic Link Library, die Unix-APIs zur Verfügung stellt. Die APIs der Cygwin-DLL bilden das Pendant zu den System Calls unter Unix. Die mit Cygwin portierten Programme sind normalerweise nicht alleine lauffähig, da sie gegen die Cygwin-DLL gelinkt werden und somit von dieser abhängig sind.

Zwar kann ich, wenn ich beispielsweise Ruby 2.0 nutzen will, es auch ganz normal unter Windows installieren und solange es sich im "Path" befindet, kann ich es unter Cygwin nutzen - aber wehe, wenn ich gems bauen will. Dann funktioniert das hinten und vorne nicht.

Wieso Ruby unter Cygwin betreiben, Ruby gibt es als nativen Windows Port:

Ruby herunterladen

Für Windows-Nutzer hat sich die Installation mithilfe des RubyInstallers etabliert, der alle notwendigen Tools für die Rubyentwicklung unter Windows mitbringt.

Um RubyInstaller zu nutzen, muss man ihn nur von der RubyInstaller-Downloadseite herunterladen und starten. Fertig!

Speziell für die Nutzung von Rails unter Windows gibt es den RailsInstaller. Dieser baut auf dem RubyInstaller auf, enthält aber noch einige weitere Werkzeuge, die die Entwicklung mit Rails vereinfachen.

Installiere ich allerdings das "Devkit" von DevKit läuft alles, wie geschmiert. Lustiger Nebeneffekt: Jetzt habe ich neben Cygwin eine zweite "Distribution" auf MSys basierned. Und wieder ein GCC und wieder eine Bash etc. pp.

Minimal SYStem

MinGW

Es dient MinGW-Entwicklern als ein minimales System, welches unter anderem configure-Skripte ausführen kann.

Ich betreibe Cygwin, MSVC und MSYS parallel ohne die von Dir genannten Probleme

Richtig spaßig wird es dann, wenn man zusätzlich noch Perl installiert. Aktuell kann man da ja 5.18 benutzen. Cygwin selbst bringt 5.14 mit.

Auch Perl gibt es als native Windowsport Perl - Download - www.perl.org

Wozu installierst Du auch 2 unterschiedliche Versionen

Und der Knaller: Installiert man Git für Windows, erhält man wieder ein komplettes MSys. Damit nicht genug, es bringt auch noch ein Perl mit sich, was in der Version 5.8 vorliegt.

Auch das stimmt so nicht:

Free Mercurial and Git Client for Windows and Mac | Atlassian SourceTree

https://code.google.com/p/tortoisegit/

Git for Windows

CommandLine und GUI Zugriff ohne Probleme möglich. Ohne dass ich jetzt nachschaue aber sofern das Binary eine DLL mitliefert und richtig installiert, sollte es kein Problem sein auch mehrere Versionen ein und der selben Software zu verwenden.

Letzte Lösung: Ich müßte mein System zu Linux migrieren. Nicht, dass ich per se was dagegen hätte -ich fühle mich da eigentlich recht zu hause- aber ich bin ansonsten mit WIN8 zufrieden und möchte nicht unbedingt (wieder) wechseln.

Das hier ist definitiv ein Flameposting und aus fachlicher Sicht hast Du hier in keiner Weise recht. Du hast sprichwörtlich Dein System nicht richtig unter Kontrolle und beschwerst Dich, dann darüber dass es nicht läuft. Ich nutze identische Software (bis auf Ruby) auf Windows 7 und zusätzlich noch Scons als Buildsystem und ich kann keines Deiner Probleme auch nur im Ansatz nachvollziehen. Scons baut in der CommandLine, sowohl Binaries mit MSVC und MinGW, aber es läuft ebenso in Cygwin. Mittels Jenkins erzeugte ich somit ohne Probleme MSVC & MinGW Binaries. Selbst in Cygwin gebaute Binaries laufen ohne Probleme, sofern man eben die passenden DLLs mit zu dem Binary liefert.

Deine Schilderungen zeugen eher davon, dass Du nicht verstanden hast, wozu die einzelnen Tools da sind und wie sie funktionieren. Je nach Anwendung braucht man weder Cygwin noch MSYS / MinGW. MSVC gibt es in der Expressversion von MS kostenlos. Möchte man eine für Linux entwickelte Komponente unter Windows kompilieren, dann muss man auf Tools wie Cygwin / MinGW zurückgreifen, oft liefern aber die Entwickler auch einen CMake Build, mit der sich die Sachen auch unter MSVC bauen lassen.

Sowohl Cygwin, wie auch MSYS / MinGW kann ich so installieren, dass beide Umgebungen sich nicht behindern bzw. mit bestehenden nativen Anwendungen einen Konflikt verursachen.

Für mich ist das hier ein Flame, wenn Du mit Windows nicht zufrieden bist, dann nimm' ein OS Deiner Wahl, wenn Du unter Windows Linux Binaries bauen willst, dann installiere dafür richtig eine passende Umgebung, wenn Du Windows Binaries bauen willst, dann nimm ein MSVC bzw. benutze den nativen Windowsport Deiner Bibliotheken/Programme

[lilith2k3]

Ich denke flash, dass Du mit dem falschen Fuß aufgestanden bist

Das ist kein Flame-Post. Was brächte es mir auch? Es geht nachwievor um die Frage, wie ich ein einheitliches System aufsetzen kann.

Vielleicht sollte ich das gesagte nocheinmal zusammen fassen, damit Du verstehst, wo das Problem ist:

1) Ich bin vollkommen zufrieden mit Windows.

2) Ich benutze Cygwin.

3) Wenn ich verschiedene Pakete in Cygwin installiere, wird automatisch ein Perl mitinstalliert, weil es sich in den Abhängigkeiten befindet. Das heißt im Klartext: Wenn ich Strawberry Perl for Windows regulär unter Windows installiert habe, anschließend die Konsole von Cygwin öffne, und ein simples "perl -v" eingebe, so erhalte ich eben "5.14" und nicht "5.18", weil Cygwin das ihm eigene Perl bevorzugt . Das heißt, jedes mal, wenn ich etwas installiert habe, wo Perl mit in den Abhängigkeiten ist, kann ich Perl (in Cygwin) manuell wieder deinstallieren.

4) Habe ich die Bash bisher als Ersatz für die CMD.exe benutzt, was es mit sich bringt, dass ich auch Ruby-Skripte unter der Cygwin/Bash schreibe und ausführe. Wenn ich allerdings ein gem "bauen" muss, wie das besagte MYSQL-gem, so geht das so ohne weiteres nicht.

5) Läuft mein System. Es ist nur unbefriedigend, wie es läuft. Ich kann beispielsweise bequem aus der Bash Ruby-Skripte starten, wenn ich allerdings gems baue, so tue ich das derzeit in der Powershell.

6) Läuft das von Dir zuletzt verlinkte Git eben auch mit MSys das ist genau das, wovon ich spach.

Btw. nutze ich tatsächlich inzwischen Atlassian Sourcetree.

Ich nutze identische Software (bis auf Ruby) auf Windows 7 und zusätzlich noch Scons als Buildsystem und ich kann keines Deiner Probleme auch nur im Ansatz nachvollziehen. Scons baut in der CommandLine, sowohl Binaries mit MSVC und MinGW, aber es läuft ebenso in Cygwin. Mittels Jenkins erzeugte ich somit ohne Probleme MSVC & MinGW Binaries. Selbst in Cygwin gebaute Binaries laufen ohne Probleme, sofern man eben die passenden DLLs mit zu dem Binary liefert.

Darum geht es doch nicht.

Je nach Anwendung braucht man weder Cygwin noch MSYS / MinGW. MSVC gibt es in der Expressversion von MS kostenlos. Möchte man eine für Linux entwickelte Komponente unter Windows kompilieren, dann muss man auf Tools wie Cygwin / MinGW zurückgreifen, oft liefern aber die Entwickler auch einen CMake Build, mit der sich die Sachen auch unter MSVC bauen lassen.

Jein. Wenn ich lediglich Ruby unter Windows installiere, so kann ich Ruby Installer nutzen, DevKit installieren und habe meine Ruhe. Ob Devkit allein ein MSYS benötigt oder nicht, stört mich keineswegs.

Das Problem, was ich oben beschrieben habe ist auch auf einen speziellen Anwendungsfall zurückzuführen:

MYSYSGit + Ruby+DevKit+Cygwin+Perl+GHCI Haskell (und alles am besten auch noch im PATH) führt dazu, dass ich mehrere Versionen von Minimalumgebungen/Linuxumgebungen auf meinem System rumfliegen habe (und ich je nach Auflösungsprio im Path mal das eine Perl oder das andere erhalte).

Und ich wiederhole nochmal meine Eingangsfrage: Läßt sich das vereinheitlichen?

Ich hoffe Du erkennst aus dem Gesagten, dass es kein Flame-Post ist.

Über Lösungsvorschläge würde ich mich freuen.

P.S.: Kennt jemand https://github.com/bmatzelle/gow/wiki ?

P.P.S: Unter einem *nixoiden System hätte ich das Problem nicht. Daher erklärt sich auch die "letzte Lösung", wenn es sich unter Windows nicht so einfach realisieren läßt, dann bleibt eben nur der Umstieg.

Bearbeitet 10. Juni 2013 von lilith2k3

[flashpixx]

3) Wenn ich verschiedene Pakete in Cygwin installiere, wird automatisch ein Perl mitinstalliert, weil es sich in den Abhängigkeiten befindet. Das heißt im Klartext: Wenn ich Strawberry Perl for Windows regulär unter Windows installiert habe, anschließend die Konsole von Cygwin öffne, und ein simples "perl -v" eingebe, so erhalte ich eben "5.14" und nicht "5.18", weil Cygwin das ihm eigene Perl bevorzugt . Das heißt, jedes mal, wenn ich etwas installiert habe, wo Perl mit in den Abhängigkeiten ist, kann ich Perl (in Cygwin) manuell wieder deinstallieren.

Du hast den Sinn von Cygwin nicht verstanden. Cygwin soll gar nicht die Windowsprogramme nutzen, denn Cygwin emuliert eine Linux Umgebung. Gerade für die Pfade existiert ein Unterschied. Cygwin bringt eine eigene DLL (cygwin.dll) die dafür sorgt, dass die unixspezifischen Aufrufe intern auf die Windows Aufrufe umgewandelt werden.

Es wäre fatal, wenn Cygwin auf einmal native Windows Tools nutzen würde. Darum sind auch die Abhängigkeiten zu Perl eben so gesetzt, dass sie konsistent innerhalb von Cygwin sind.

Außerhalb von Cygwin bist Du selbst dafür verantwortlich.

Aber dies steht ganz genauso beschrieben in der Dokumentation von Cygwin !

4) Habe ich die Bash bisher als Ersatz für die CMD.exe benutzt, was es mit sich bringt, dass ich auch Ruby-Skripte unter der Cygwin/Bash schreibe und ausführe.

Weder Cygwin noch Bash sind ein Ersatz für die Windows CommandLine ! Auch das steht in der Dokumentation. Cygwin ist eine Umgebung um unter Windows ein unixoxides System zu emulieren, damit es möglich ist Unixtools unter Windows zum laufen zu bekommen (d.h. zu compilieren und zu linken). Dadurch entstehen eben zu den Cygwin spezifischen DLLs entsprechende Abhängigkeiten.

Das Problem, was ich oben beschrieben habe ist auch auf einen speziellen Anwendungsfall zurückzuführen:

MYSYSGit + Ruby+DevKit+Cygwin+Perl+GHCI Haskell (und alles am besten auch noch im PATH) führt dazu, dass ich mehrere Versionen von Minimalumgebungen/Linuxumgebungen auf meinem System rumfliegen habe (und ich je nach Auflösungsprio im Path mal das eine Perl oder das andere erhalte).

Das ist eben die Definition des Path. Aber das ist kein Problem, denn z.B. die MSVC CommandLine ist nichts anderes als eine normale Windows CommandLine, bei der beim Start mittels Batchdatei diverse Umgebungsvariablen gesetzt werden. Gleichen Mechanismus kann man mit minimalen Aufwand selbst nachbauen !

Vor allem musst Du dann hier nicht flamen, dass das nicht funktioniert (ich bin auch nicht mit dem falschen Bein aufgestanden). Du kritisierst hier, dass es nicht läuft, denn Du versuchst aktuell eine Feinmechanikerschraube mittels Vorschlaghammer in die Wand zu bekommen und Du beklagst Dich, warum Deine Wand Schaden nimmt.

Windows hat nicht wie ein Linux einen zentralen Paketmanager, aber mit ein bisschen Nachdenken kann man sein System so konfigurieren, dass man mit unterschiedlichen Umgebungen in unterschiedlicher Weise arbeiten kann. Ich nutze z.B. SCons (SCons: A software construction tool) und erzeuge mittels MinGW, MSVC und Cygwin Binaries.

Für MSVC und MinGW nutze ich ein ActivePython mit passender MSI Installation von SCons, in Cygwin nutze ich das Cygwin Python mit der Tar.Gz Version von SCons. Meine kompilierten Binaries laufen auch "nativ" unter Windows, sofern ich eben die notwendigen DLLs für das Binary passend zur Verfügung stelle.

P.P.S: Unter einem *nixoiden System hätte ich das Problem nicht. Daher erklärt sich auch die "letzte Lösung", wenn es sich unter Windows nicht so einfach realisieren läßt, dann bleibt eben nur der Umstieg.

Das Problem wird sich nicht dadurch regeln, welche Tools Du installierst, sondern dadurch dass Du verstehst was sie machen. Auch unter Linux gibt es diesen Fall nämlich beim Cross-Compiling muss ich die Glib mehrfach installieren, nämlich für jede Targetplatform. Die entsprechende Zuordnung mache ich dann mittels Umgebungsvariablen und dies geht unter Windows analog.

Wie schon gesagt ist Dein Post für mich ein Flame, weil Du hier die Schuld an Deinen Problem Windows gibst. Die Schuld liegt aber bei Dir, denn Du benutzt die Tools nicht ihrer Spezifikation nach und wunderst Dich dann, dass es zu Schwierigkeiten kommt. Benutze die Tools so, wie es gedacht ist und nicht wie Du denkst, dass sie funktionieren müssten.

[lilith2k3]

Nein, ich gebe nicht Windows die Schuld, sondern will eine "einheitliche Lösung" unter Windows. Aber auch wenn ich das nochmal wiederhole scheinst Du das zu ignorieren.

Wie löst sich das Problem, mehrere MSys Installationen auf meinem System haben zu müssen?

Eine Lösung wäre ja: "Installiere ABCD, setze Deine Pfadvariable und wenn Du dann HIJKL nutzen willst, findet es alles im Pfad" eben eine Lösung.

Bearbeitet 10. Juni 2013 von lilith2k3

[flashpixx]

Wie löst sich das Problem, mehrere MSys Installationen auf meinem System haben zu müssen?

Deine Programme sind nicht gegen MSYS gelinkt, sondern sondern gegen die DLLs die MSYS mitbringt

Eine Lösung wäre ja: "Installiere ABCD, setze Deine Pfadvariable und wenn Du dann HIJKL nutzen willst, findet es alles im Pfad"

Es ist so zu lösen, wie man die Abhängigkeiten bei jedem Windows Programm auch auflöst und dazu gibt es mehrere Wege, den Pfad verändern, ist eine davon. Eine andere regsvr oder eben die DLLs in passende Verzeichnisse zu legen.

RTFM http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

Bearbeitet 10. Juni 2013 von flashpixx

[lilith2k3]

Ich denke, wir sollten den Thread hier schließen.

Im Grunde reden wir aneinander vorbei.

[lilith2k3]

Falls es noch jemanden interessiert: auf Stack Overflow ist man ein wenig kooperativer

The version of msys that is included in the Git for Windows package is modified and if you attempt to replace it with a stock msys package you will run into problems. I can't comment on the other packages but basically - it is not worth worrying about. Disk space is significantly cheaper than the time you spend trying to make a number of independent packages share a common msys platform.

However, there are in fact people working on trying to sort that out. msys now has a package management system and I know of at least one project attempting to get the Git for Windows build environment working withing that system mingwGitDevEnv

https://github.com/sschuberth/mingwGitDevEnv

Zu deutsch: Derzeit ist es eben ein notwendiges Übel, wenn man mehrere dieser Systeme installiert hat. Es handelt sich um einen offensichtlich "bekannten Mißstand". Und derzeit muß man noch damit leben. Das heißt, es gibt derzeit keine Einheitlichkeit.

[flashpixx]

Falls es noch jemanden interessiert: auf Stack Overflow ist man ein wenig kooperativer

[...] Das heißt, es gibt derzeit keine Einheitlichkeit.

Genau das hatte ich Dir geschrieben:

Dadurch entstehen eben zu den Cygwin spezifischen DLLs entsprechende Abhängigkeiten. [...] Windows hat nicht wie ein Linux einen zentralen Paketmanager, [...]

Diese Aussage gilt aber für jedes Windows Programm und ist nicht spezifisch für Deine Buildumgebung.

[lilith2k3]

Ich denke das Mißverständins hat verschiedene Ursachen:

Ich habe den Begriff "Buildumgebung" falsch benutzt. Du hast auf Grund der Bezeichnung "Buildumgebung" richtig angenommen, dass ich von Compiler-Umgebung spreche; tatsächlich wollte ich eigentlich in keinem Fall kompilieren. Insofern spielt Cygwin und die Bindung an die Cygwin.dll keine Rolle. Gleiches gilt für MSys, was zwar eine unix-like Buildumgebung ist, aber native Binaries kompiliert, und keine Bindung wie Cygwin an einen Emulationslayer benötigt.

Das Problem besteht darin, daß noch keine einheitliche Lösung für MSys in Verbindung mit den verschiedenen Open Source Projekten unter Windows geschaffen worden ist. Viele Projekte kommen eben aus der *nix-Welt und dort hat man eben ein funktionierendes Ökosystem an Kommandozeilentools. Unter Windows gibt es bisher nur als "Notbehelf" MSys. Und für die einzelnen Projekte ist es anscheinend leichter, wenn jedes Projekt die Buildtools mitbringt, die es benötigt - die notfalls eben redundant auf der Platte liegen.

Und das ist kein Nachteil von Windows, sondern im Gegenteil: es gibt -abgesehen von dem oben erwähnten Projekt- kein großes Projekt, welches dafür sorgt, das zu vereinheitlichen.

Meine Vorstellung war:

MSys wird an einer Stelle zentral installiert. Wenn dann beispielsweise DevKit verschiedene Libs/Tools whatever mitbringt, werden die einfach unter /lib /bin im MSys-Folder abgelegt. Oder, wenn eine Abhängigkeit zu Perl besteht, wird erkannt, dass Perl bereits installiert ist.

Das setzt natürlich eine Verwaltung der Abhängigkeiten voraus - was aber wiederum kein Nachteil von Windows ist, sondern eben ein "Nachteil" von MSys.

Eine mögliche Lösung wäre gewesen: die redundanten Systeme manuell aufzulösen (von dem mir allerdings aufgrund der Ausführungen bei Stack Overflow) abgeraten worden ist. Technisch machbar, aber zu aufwendig.

In Summa heißt das:

Entweder, ich muss damit leben, dass vorerst mehrere redundante MSys-Installationen parallel auf der Platte liegen (Space is cheap), oder ich muss tatsächlich zu *nix migrieren, wenn es mir so wichtig ist.

P.S.: Also wenn überhaupt: ist es ein Pro-Windows-Flame Post; auch mal interessant als Windows Nutzer benachteiligt zu sein.

P.P.S.: Weiß ich in der Tat erst seit gestern, wo der Unterschied zwischen Cygwin und MSys ist.

Bearbeitet 11. Juni 2013 von lilith2k3

[flashpixx]

Das Problem besteht darin, daß noch keine einheitliche Lösung für MSys in Verbindung mit den verschiedenen Open Source Projekten unter Windows geschaffen worden ist. Viele Projekte kommen eben aus der *nix-Welt und dort hat man eben ein funktionierendes Ökosystem an Kommandozeilentools. Unter Windows gibt es bisher nur als "Notbehelf" MSys. Und für die einzelnen Projekte ist es anscheinend leichter, wenn jedes Projekt die Buildtools mitbringt, die es benötigt - die notfalls eben redundant auf der Platte liegen.

Wie schon geschrieben, ist das ja "nur" eine Frage der DLLs. MSYS bringt ja z.B. die pthread etc mit. Wie ich ja geschrieben habe, kannst Du das Problem durch entsprechende Konfiguration des Systems lösen. Eine MSYS Installation und diese korrekt im System verankern und dann sich "nur" die Binaries des jeweiligen Projektes holen bzw. die DLLs des Projektes entfernen.

Dann hast Du "eine" MSYS Installation und alle Executables greifen auf diese DLLs zurück.

MSys wird an einer Stelle zentral installiert. Wenn dann beispielsweise DevKit verschiedene Libs/Tools whatever mitbringt, werden die einfach unter /lib /bin im MSys-Folder abgelegt. Oder, wenn eine Abhängigkeit zu Perl besteht, wird erkannt, dass Perl bereits installiert ist.

DevKit kenne ich nicht (ich entwickle nicht mit Ruby), aber im Grunde sollte es genauso möglich sein. Du musst eben nur die Pfade korrekt anpassen.

Eine mögliche Lösung wäre gewesen: die redundanten Systeme manuell aufzulösen (von dem mir allerdings aufgrund der Ausführungen bei Stack Overflow) abgeraten worden ist. Technisch machbar, aber zu aufwendig.

sehe ich eigentlich auch so. Ich organisiere meine Projekte immer so, dass ich alle Libs, die zu einem Projekt gehören innerhalb eines Verzeichnis des Projektes liegen habe und nicht gegen die Libs im System linke (sofern es nicht OS spezifisch ist).

Das hat einfach den Grund, dass ich unterschiedliche Versionen der Lib haben kann und testen kann, ob meine Programmierung sich mit unterschiedlichen Versionen verträgt.

Das was ich eben "global" habe, sind die Entwicklungstools (Compiler & Linker).

Entweder, ich muss damit leben, dass vorerst mehrere redundante MSys-Installationen parallel auf der Platte liegen (Space is cheap), oder ich muss tatsächlich zu *nix migrieren, wenn es mir so wichtig ist.

Ich stell mal die Frage danach "was" willst Du überhaupt machen? Ich denke eigentlich, dass Du evtl ganz gut damit fahren könntest, wenn Du Dir für die Buildumgebungen entsprechende Batch-Scripte baust und dann diese in der Commandline passend nutzt, also im Grunde Deine eigene Shell baust.

P.P.S.: Weiß ich in der Tat erst seit gestern, wo der Unterschied zwischen Cygwin und MSys ist.

*g* das hat man gemerkt :-P

Ich nutze versuche immer Libs zu finden, die z.B. einen nativen CMake Build dabei haben, dann kann ich die Lib auch unter MSVC kompilieren, das macht es deutlich einfacher. MSYS selbst brauchst Du "nur", wenn das Projekt im Grunde ein Autoconf Script mit bringt und Cygwin eben, wenn Du eine vollständige Emulation brauchst (das wird aber sehr langsam).

GCC für Windows kommt meines Wissen als Zip mit, d.h. Du bekommst alle DLLs und Tools einfach so und kannst sie eben hinlegen wo Du willst und musst dann eben nur für die Executables die DLLs passend zugängig machen.

Ich nutze den GCC für Windows direkt unter der Windows eigenen CommandLine und das funktioniert sehr gut. Auch das compilieren von diversen Libs z.B. Boost läuft ohne große Probleme damit. Bei mir liegt unterhalb des Projektverzeichnisses ein Verzeichnis "library/<release|debug>/<library name>/<version>/". Das erzeugen der Libs also vom Download, entpacken, compilieren & installieren übernimmt ein SCons Script. Ich gebe "nur" auf der Commandline "scons library" ein und das Script checkt, ob eine neue Version der Lib da ist, wenn ja compiliert er sie passend und wirft sie in das Verzeichnis. Baue ich mein Projekt, wird als Default immer die "neuste" Version verwendet bzw. andere gebe ich per Parameter an.

Bearbeitet 11. Juni 2013 von flashpixx

[lilith2k3]

Die ursprüngliche Idee war: Da ich auf 3 Systemen unterwegs bin/war (Mac auf der Arbeit, Windows und Linux zu Hause -ist momentan allerdings ein Win8 Laptop, der alte is putt), wollte ich eine einheitliche "Shell"-Umgebung haben. Bisher habe ich sämtliche Konsolenaufgaben unter Cygwin erledigt (e.g . "grep" und "sed" sind die Tools meiner Wahl). Und eben auch da meine Skripts geschrieben. Mir geht es auch nicht darum, Produktivsoftware zu bauen, sondern vorallem, mich in verschiedenen Paradigmen und Sprachen zu schulen. Deswegen auch die bunte Mixtur aus Sprachen.

Da ich bisher nichts für Windows kompilieren mußte, sondern lediglich aus Cygwin heraus Perl, Python, Ruby oder was auch immer aufgerufen habe, habe ich auch keine Probleme gehabt. Und das Schema touch->chmod->vim ist mir in Fleisch und Blut übergegangen, so daß ich das gerne auch unter Windows nutzen wollte. Da kam mir Cygwin gerade recht. Und bis dato habe ich MSys nur für eine "Alternative" gehalten, aber nicht gewußt, wo der essentielle Unterschied liegt.

DevKit kenne ich nicht (ich entwickle nicht mit Ruby)

Devkit kommt immer dann zum Einsatz, wenn etwas "nativ" gebaut werden muss, wie eben das SQL-Modul (was unter Windows auch gegen die libmysql.dll gelinkt wird). Insofern ist es auch logisch, daß dazu ein MSys und kein Cygwin benutzt wird.

Das, was ich eigentlich hätte nutzen sollen, wäre GoW gewesen, da es sich um native Win-Anwendungen handelt. Alles in allem habe ich Cygwin komplett deinstalliert und arbeite mit den nativen Windows Ports der Sprachen aus der Powershell und lebe mit einem dutzend MSys-Paketen :]

[flashpixx]

(e.g . "grep" und "sed" sind die Tools meiner Wahl).

Die beiden gibt's IMHO vom GNU Projekt auch als native Version, da brauchst Du weder Cygwin noch MSYS

Und eben auch da meine Skripts geschrieben. Mir geht es auch nicht darum, Produktivsoftware zu bauen, sondern vorallem, mich in verschiedenen Paradigmen und Sprachen zu schulen. Deswegen auch die bunte Mixtur aus Sprachen.

Das hab ja eigentlich nicht's mit der Umgebung zu tun.

Und das Schema touch->chmod->vim ist mir in Fleisch und Blut übergegangen, so daß ich das gerne auch unter Windows nutzen wollte.

Touch und chmod brauchst Du eigentlich nicht unter Windows. Und Vim gibt es auch als Windowsport.

Devkit kommt immer dann zum Einsatz, wenn etwas "nativ" gebaut werden muss, wie eben das SQL-Modul (was unter Windows auch gegen die libmysql.dll gelinkt wird). Insofern ist es auch logisch, daß dazu ein MSys und kein Cygwin benutzt wird.

Aber da muss ja der passende Compiler auch existieren.

Das, was ich eigentlich hätte nutzen sollen, wäre GoW gewesen, da es sich um native Win-Anwendungen handelt. Alles in allem habe ich Cygwin komplett deinstalliert und arbeite mit den nativen Windows Ports der Sprachen aus der Powershell und lebe mit einem dutzend MSys-Paketen :]

Wenn Du so etwas haben willst, dann würde ich empfehlen, dass Du Dir z.B. Projekte wie HomeBrew & MacPorts anschaust, denn wenn man jetzt z.B. MinGW als Compiler installiert, könnte man man schauen welche Pakete sich eben passend für Windows portieren lassen. HomeBrew basiert auf Ruby, d.h. da könnte man sich wirklich mal überlegen ob man vielleicht jedenfalls in Teilen einen Windowsport erstellen kann.

[flashpixx]

Homebrew ist ja eigentlich "nur" ein Git Repo mit entsprechenden Ruby basierten Buildscripten bzw. OS abhängigen Buildeinstellungen. Evtl könnte man sich da wirklich das einfach mal via Github forken und mittels MinGW dann für Windows verfügbar machen. Sicherlich lässt sich nicht alles portieren, aber probieren könnte man es mal