[linux-l] Cygwin Lizenz

[Volker Grabsch]

Steffen Dettmer <steffen at dett.de> schrieb:
> * Volker Grabsch wrote on Mon, Sep 29, 2008 at 16:17 +0200:
> > Es ging nicht darum, mit welchen Tools die Software erstellt
> > wurde, sondern welche Libraries sie zur Laufzeit benötigt.
> 
> MinGW ist doch genau dafür da:
> 
> http://www.mingw.org/
>   MinGW: A collection of freely available and freely
>   distributable Windows specific header files and import
>   libraries, augmenting the GNU Compiler Collection, (GCC), and
>   its associated tools, (GNU binutils).
[...]
> ... und natürlich muss man die Software mit der MinGW Umgebung
> bauen, damit sie dann unter native Windows läuft.

Wir reden aneinander vorbei, aber das tut eh nichts zur Sache.

> > > Hast Du mal was mit MinGW gemacht und wie waren die Erfahrungen?
> > 
> > Was ebenfalls sehr gut funktioniert: Nimm die Entwicklungs-
> > Werkzeuge direkt von Unix, entwickle unter Unix, und wirf einen
> > MinGW-Crosscompiler an. 
> 
> ...dann geht bei automake mindestens `make check' nicht.
> So in etwa war damals allerdings auch meine Idee: man nehme halt
> nur Basisfunktionen in seiner lib, implementiere notfalls paar
> kleine Module neu, entwickle unter Linux und für Win32 einfach
> ein Crosscompiler-Lauf. Leider ging dann doch vieles nicht, und
> als ich endlich .exe-Files hatte, funktionierte ne Menge nicht.
> Zum Debuggen von platform-spezifischen Problemen halte ich
> crosscompiling nicht für geeignet.

Austesten kann man die meisten Programme auch mit Wine.

Ü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.
Insbesondere wird das Compilieren externer Libraries nochmals
einfacher. Mein mingw_cross_env würde dabei sicher ordentlich
schrumpfen.

> > Dann brauchst du dir um die Tools keine Sorgen zu machen,
> > sondern nur noch um den Compiler und die Libraries.  Ersteres
> > gibt's 100fach im Netz, letzteres gab es kaum. Daher hatte ich
> > zu dem Zweck ein Projekt ins Leben gerufen, das haufenweise
> > Libraries unter MinGW zum Cross-Compilieren verfügbar macht:
> > 
> > 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 ?

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".

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.

Man *kann* auch wie wild irgendwelche Funktionen und Abstaktions-
schichten einführen. Praktisch alle anderen Build-Cross-GCC-Scripte
machen das auch - sie waren für mich ein warnendes Beispiel. Die
Dinger sind eine Zumutung für den Leser. Man braucht Ewigkeiten,
um elementare Details nachzuvollziehen, z.B. welche Parameter das
./configure nun letztendlich erhält.

Nein, die Schwächen meines Scriptes sehe ich ganz woanders:

* Für jedes Programm/Library sollte es eine einzelne Datei geben,
  die einzeln gestartet werden kann. Das erleichtert das Testen
  ungemein.

* Es sollte kein Shellscript, sondern ein Makefile sein. Dann
  braucht man beim Upgrade einer Library nur die Sachen neu
  bauen, die davon wirklich betroffen sind. Und Parallelisierung
  gibt's dazu geschenkt.

* 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.

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)

> 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.

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

> Ich wollte eigentlich bloss wissen, wieviel man da inzwischen
> erwarten kann - von Anwendungen, die nicht extra dafür gemacht
> sind. Kann man eine Shell z.B. einfach mal so unter mingw
> übersetzen?

Ja.

> vim wohl nicht, denn der beigelegte funktionierte
> überhaupt nicht.

Das wundert mich. Ich hab's zwar nicht probiert, aber es _müsste_
eigentlich gehen.

> 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 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.


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR