On Fri, 2004-03-12 at 11:41, Andreas Loesch wrote:
Ralf Corsepius wrote:
KDEStudio kenne ich nicht, doch sollte die Abhilfe einfach sein: Alte autoconf/automake's installiert und es sollte wieder tun.
dann funktionieren 101 andere Sachen nicht mehr :( fällt leider aus Da muss einiges im Argen liegen. Die alten auto*tools unter einem Nicht-Standard-Prefix zu installieren sollte immer funktionieren.
Oder sollte es sich bei KDEStudio um einen Fall von Vaporware handeln, die nicht weiter gepflegt wird?
naja, für Version 3.3.5 schreiben Sie zwar * updated for autoconf 2.57, automake 1.7 aber der Erfolg ist IMHO nicht so gross :) Wenn sich die standard-projektfiles nicht übersetzen lassen....
Ergebnis :) KDEStudio wurde von uns in die Ecke geworfen, mit KDevelop3 wird man glücklicher, insbesondere da hier die qmake Unterstützung einbebaut ist. Das gleiche habe ich mit kdevelop gemacht ...
[qmake automake und portabilität]
könnte man noch cmake ins Rennen schicken, da habe ich mit der vtk auch noch keine Probleme gehabt und ist ebenfalls sehr portabel.
Noch'ne Insel ... Im Ernst, wir sind hier beim Thema "Proprietäre Lösung/Insellösung vs. Portabilität" gelandet.
Sorry, aber cmake (http://www.cmake.org/HTML/Index.html) ist genau so eine Opensource Insel, wie autoconf/automake.
Jein, momentan würde ich es als ein exotisches, wenig verbreites Tool einstufen, über das kaum Erfahrungswerte vorliegen, über dessen langfristige Perspektiven keine Aussage möglich ist und das scheinbar auf diskutablen Funktionsprinzipien basiert. Auch die Liste der Referenzanwendungen spricht nicht unbedingt für sich. Ähnliche Tools hat es schon viele gegeben, gibt es immer wieder und wird es immer wieder geben. Eine zeitlang waren GUI-basierte Projectbuilder in Mode, manche haben versucht Alternativen zu "make" zu etablieren, andere versuchten sich in "meta"-Prozessoren zu make, usw. usf. Bestand hatten bislang nur wenige, durchgesetzt haben sich noch wenigere. Interessant erscheinen mir im Moment ant (java) oder jam (boost/C++). Verwendet habe ich bislang allerdings noch keines dieser Tools, weil ich mit den autotools relativ gut auszukennen glaube und bislang keinen Bedarf hatte, mich nach Alternativen umzusehen. autoconf/automake sind weit verbreitet, seit langem im Gebrauch (ca. 10 Jahre) und GNU-Standard. Allerdings leiden beide an "Krankheiten", die ihren Ursprung in ihrer Historie haben und an Usern, die zwar kein Problem damit haben alle 1/4 Jahr oder noch öfters ihren Quellcode an die momentane Implementation eines GCC und die sich laufend änderenden APIs ihrer Toolkits anzupassen, gleichzeitig aber erwarten, dass aktuelle auto*tools kompatibel zu 3-4 Jahre alten Versionen sind ;)
Insbesondere: autoconf/automake läuft wunderbar auf Unixoiden Maschinen aber die Windows Unterstützung ist AFAIK nahe Null, evtl. mit cygwin aber sonst.... Mit Einschränkung gebe ich dir recht. Die Autotools setzen aber keine Unixoide Umgebung voraus, sondern eine POSIX-Laufzeitumgebung (+Perl). Da die Windows-Laufzeitumgebung alles andere als POSIX-konform ist, ist es nicht einfach die Autotools unter Windows zu verwenden. Nichtsdestotrotz scheint es zu gehen, vgl. z.B. http://www.coin3d.org/Coin/faq.php#Q1.5
Von anderen Personen wurde mir berichtet, dass sie autoconf/automake unter MinGW verwenden würden, wiederum andere verwenden autoconf/automake unter Cygwin als Entwicklungsumgebung um Win-Binaries zu erzeugen. Wiederum andere verwenden Cross-Entwicklungsumgebungen unter *nix um Binaries für Windows zu erzeugen (Zu diesen gehöre ich). Doch wo ist das Problem? Betrachte Cygwin als doch als Entwicklungsumgebung, genauso wie Du vermutlich Qt und/oder einen C++-Compiler unter Windows bzw. x*10MB KDE/Qt unter Linux installiert hast.
Insellösungen haben immer im Augenblick Vorteile, ob Insellösungen aber langfristig tragen oder nur zeitweise Mode-Strömungen sind, weiss keiner. Die wirklichen Probleme entstehen dann, wenn eine Insellösung zur wirklichen Insel wird (Projekt gestoppt, Produktlinie beendet u.ä.).
das Problem hast Du immer, egal, wohin Du blickst. makefiles sind wunderbar, wenn ich aber da eine Meta-Sprache drüberlege kommt es auf die Zielplattformen an, Das scheint mir der grundlegende Unterschied zwischen autoconf/automake und cmake zu sein.
autoconf/automake verwenden eine POSIX-Laufzeitumgebung (+perl) und eben keine "native" Laufzeitumgebung (Kein COMMAND.COM o.ä.). Bei cmake scheint das, wenn ich die FAQ richtig überflogen habe, anders zu sein.
autoconf/automake sind im Unix-Bereich _sehr_ weit verbreitet und die sind auch gut ausgreift keine Frage aber sind u.u. nicht die perfekte Wahl. Perfekt sind autoconf/automake weiss Gott nicht, aber die Resultate, die sie produzieren sind in einem Maß portabel, dass man in manuell geschriebenen Makefiles praktisch nicht realisieren kann - Damit fing es in diesem Thread doch an.
Ralf