On Fri, 2004-03-12 at 09:34, Andreas Loesch wrote:
Ralf Corsepius wrote:
Meine (zugegeben launische) Anmerkung bezog sich darauf "eigene, händisch geschriebene" Makefiles statt "durch ein Tool generierte" Makefiles zu verwenden:
im weitensten Sinn Ack (wobei ein verständnis für Makefiles nicht verkehrt ist und daher auch ein manuell geschriebenes zu Anfang helfen kann. Klar, man muss erst alle Fehler selbst erst einmal gemacht haben, bevor man den Sinn der Tools versteht.
* Ab einer gewissen Projektgrösse werden "eigene Makefiles" in der Regel _schnell_ derart komplex, dass man praktisch keine Chance hat, diese Komplexität auch nur annähernd zu bewältigen.
nicht unbedingt, man muss nur mehr Zeit investieren, ... extrem viel Zeit ... es bleibt schwierig, selbst wenn Portabilität keine Rolle spielt:
Beispiel: Die Linux-Kernel Makefiles. Portabilität spielt keine Rolle, reine gmake, nur Linux als Ziel-Plattform, 12 Jahre Entwicklungzeit, 10^x Entwicklern beteiligt, trotzdem bis einschliesslich 2.4.x doch nur bescheidene Qualität. Mit den 2.6er Kernel soll sich was verbessert haben, doch habe ich es mir noch nicht angesehen ;) Wenn Portabilität ins Spiel kommt, wird das ganze noch weitaus schwieriger.
aber dafür gibts ja die Tools ;) Man muss mit den Tools auch umgehen können (was nicht viele können), die Tools müssen gepflegt werden und die Quellen müssen gepflegt werden (was nicht viele tum).
Die meisten Leute scheinen von der Vorstellung "Einmal implementiert, Deckel zu" auszugehen, und zu vergessen, dass sich die Infrastruktur von Paketen ebenfalls weiterentwickelt.
* Verwendet man Tools, erhält man als Seiteneffekt oft (Makefile/Projektkonfigurations-) Features, die ein Projekt momentan zwar nicht braucht, sich längerfristig aber auszahlen. In bez. auf automake ist dies z.B. Portabilität.
NACK. Ich habe hier ein Beispiel vor mir liegen, ein C++-Projekt, ca 100.000 Zeilen Code und viele statische Libs und noch mehr Source und Headerfiles.
Die Masse ist nicht so entscheidend, auf die Komplexität der Konfiguration kommt es an.
Historie: das Programm wurde mit KDEStudio Gold gebastelt (autoconf/aufotmake) (Version weiss ich jetzt nicht auswendig, aber die 'ältere') und zum einen lässt es sich unter einer aktuellen Linux Distri (z.B. Suse 9 nicht erstellen!) und auch auf dem ursprünglichen Rechnerpark geht nix meht :( da wurde zwischenzeitlich autoconf/automake aktualisiert.... KDEStudio kenne ich nicht, doch sollte die Abhilfe einfach sein: Alte autoconf/automake's installiert und es sollte wieder tun.
Oder sollte es sich bei KDEStudio um einen Fall von Vaporware handeln, die nicht weiter gepflegt wird?
ich kann die Fehlermeldung jetzt nicht nachsehen, aber solltest Du einen guten Link haben, in dem die _manuelle_ Portierung der alten Autoconf/automake Dinger auf die neue Version beschrieben ist, würde ich um einen link bitten. Es ist relativ einfach: Neue autotools installieren, autoreconf -Wall starten und den Warnungen nachgehen.
Für configure-Scripte gäbe es noch autoupdate, das bei halbwegs sauberen und nicht zu komplexen Scripten recht gut funktioniert. Allerdings können sich die Details recht schwierig gestalten, insbesondere dann, wenn configure Scripte Interna alter autoconf Versionen verwenden (Davon gibt es leider zahlreiche).
[qmake]
Wie leistungsfähig es wirklich ist, kann ich nicht beurteilen, da ich noch nie den Bedarf gesehen habe, qmake verwenden zu wollen.
ich finde es _sehr_ gut, insbesondere da ich häufig MS/Linux Portabilität brauche und dafür auch Qt einsetze, Ich verwende weder Qt noch MS, dafür aber andere OSe.
als Alternative 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.
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.ä.). Ralf