[linux-l] Cygwin Lizenz

[Steffen Dettmer]

* Volker Grabsch wrote on Tue, Oct 07, 2008 at 01:11 +0200:
> Übringes habe ich mal eine interessante Idee gehört, die ich
> leider noch nicht umsetzen konnte: Man nehme sich MinGW+MSYS für
> Windows (kein Crosscompiler) und starte das unter Wine.
> 
> Der Vorteil: Die meisten Crosscompiling-Probleme verschwinden.

... aber das Starten unter Wine ist weder besonders komfortabel
(make check geht immer noch nicht) noch besonders gut zum Testen
geeignet, fürchte ich.

Bleibt aber die Frage, wie gut das MSYS nu ist. Wenn man viel
portieren muss, kann man auch auf CL.EXE portieren, den gibts
inzwischen ja wohl auch kostenlos (sicherlich aber natürlich
nicht frei, was mindestens ein indirekter Nachteil ist).

> > > http://www.profv.de/mingw_cross_env/
> > 
> > (wow, da regiert der C&P Teufel aber ;))
> 
> Unter den Scripten, die es dafür gibt, ist es mit Abstand
> das schlankeste. Das C&P täuscht, weil wiederholte ähnliche
> Fallunterscheidungen auftauchen. Würde ich das in einer
> anderen Sprache schreiben, wären das viele Funktionen, die
> die gleichen Parameter entgegen nehmen. Wäre sowas ebenfalls
> in deinen Augen ebenfalls C&P ?

Die Grenzen sind natürlich fliessend, aber riecht schon bisschen
so, als ob man vielleicht source code generation in Betracht
ziehen sollte.

> Was den immer wieder gleichen Ablauf angeht: Ja, es ist
> natürlich ständig "säubern, entpacken, patchen, configure,
> make, installieren". Aber an all diesen Punkten unterscheiden
> sich die Libraries. Würde ich das auslagern, hätte ich
> allgemeinere Funktionen, die aber viele, viele Parameter
> bräuchten, und deren Aufruf damit noch schwerer zu verstehen
> wäre, als eine simple Abfolge von "tar", "./configure", "make".

ja, lesbar ist das so auf jeden Fall am besten, einfach ist eben
einfach, stimmt. Aber den Kram jeweils in /tmp/$NEW zu bauen und
das dann zu leeren, so ähnlich die RPM das macht, ginge das
nicht?

> Ich habe mit Absicht jeden Buildvorgang komplett hingeschrieben,
> damit es keine versteckten Details gibt, die man woanders nach-
> schlagen muss. Denn genau auf diese Details kommt es an. Gute
> Lesbarkeit, Verständlichkeit und Anpassbarkeit waren meine
> Hauptkriterien für das Script. So kann man jedes "Build-Rezept"
> isoliert verstehen und direkt an der Kommandozeile ausprobieren.

Ja, das stimmt. Bei den vielen Builds kriegt man kaum noch (ohne
Probieren) raus, was das make am Ende macht...

> * Man sollte es unter einer bash in MinGW+MSYS laufen lassen können.
>   Gut, bei einigen Libraries wird das schwierig, wenn sie Python oder
>   Perl zum Bauen brauchen, aber die meisten machen da keinen Ärger.
>   Unter Linux nimmt man dann keinen Crosscompiler, sondern Wine.
>   Vorteil: Mein Script wäre um einiges einfacher und es wären weniger
>   Patches nötig. Nachteil: Das Script würde dann auch unter Windows
>   laufen, und damit Druck von den Entwicklern nehmen, sich ein Linux
>   oder *BSD zuzulegen.

Versteh nicht, warum WINE einfacher sein soll, als crosscompiler?
Weil die configures so buggy sind? Das würde mich nicht wundern,
denn autoconf ist echt Hammerkompliziert...

> Was den letzten Punkt angeht: Ich bin mir ohnehin nicht sicher,
> ob dieses Script der freien Software - politisch gesehen - mehr
> nützt oder mehr schadet. Ich muss einfach darauf vertrauen, dass
> die Entwickler es nur zum Crosscompilieren von Tools verwenden,
> die es sowieso schon in anderer Form für Windows gibt. Ich habe
> auch schon den Support für eine der Libraries (libowfat) auf Wunsch
> des Library-Autors (Fefe) wieder heraus geworfen.
> 
> BTW, wenn es nach Eric S. Raymond geht, ist das Script so lange in
> Ordnung, wie es keine Win64-Architektur unterstützt. ;-)
> (http://catb.org/esr/writings/world-domination/world-domination-201.html)

wieso, lass die Leute doch Win nehmen und Blueray mit Blut
bezahlen, wenn sie denn müssen. Maximal kommt am Ende eine
natürliche Auslese.

> > Ja, schön, dass es sowas gibt, da muss man dann nicht bei 0
> > anfangen, wenn man was portieren will oder so. Da ist SDL dabei -
> > die bringt doch schön Win32 Unterstützung mit, oder? Sonst würde
> > da vermutlich nicht so viel funktionieren...
> 
> Die Win32-API wird bereits das MinGW-Projekt zu Verfügung gestellt.
> Deshalb besteht MinGW nicht nur aus "gcc" und "binutils", sondern
> auch aus "win32api" und ähnlichem.

na super, das kann doch nu aber wirklich jeder win compiler. Das
Tolle ist doch, dass man auch POSIX Funktionen hat?

> Ansonsten: Ja, SDL unter Windows nutzt natürlich die win32-API,
> genauso wie es unter Linux die X11-API nutzt.

Ich würde mal raten, dass man SDL auch mit CL.EXE bauen kann (und
anderen).

> > vim wohl nicht, denn der beigelegte funktionierte
> > überhaupt nicht.
> 
> Das wundert mich. Ich hab's zwar nicht probiert, aber es _müsste_
> eigentlich gehen.

Na mach doch mal ne MinGW shell auf und tippe "vi" ein und guck,
ob Du da ein hello world schreiben kannst?

> > Auch bei cygwin muss man oft portieren, aber da
> > bin ich immer wieder überrascht, was da alles emuliert wird und
> > wie gut das funktioniert, schon Hammergeil.
> 
> Ja, Cygwin ist schon beeindruckend. Nur eben lahm, läuft nicht
> unter Wine

cygwin unter wine? Warum hin- und herwrappen? Kann man doch
beides weglassen und OS aufrufen?

> und die "Emulation" z.B. eines Unix-Dateisystems
> geht meistens nach hinten los. Zum Beispiel ist es ätzend,
> dass man dem (mit Cygwin gebauten) Rsync unter Windows keine
> Windows-Pfade "C:\..." übergeben kann.

Ich glaub, das geht prinzipiell, man muss nur quoten bis der Arzt
kommt, aber jedenfalls gibt's ja cygpath, das geht oft. Toll ist,
dass es eine rsync distro gibt, wo weder cygpath dabei ist, noch
/cygdrive/c noch c:/ geht... Frag mich, wie man das überhaupt
benutzen soll; vielleicht mit relativen Pfaden und rsync protocol
lol

Gibts eigentlich inzwischen rsync für native windows? Ohne diese
Probleme? Hätt gern sowas für win backups.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.