Am Freitag, den 03.03.2006, 12:56 +0100 schrieb Enrico Weigelt: > * Daniel Leidert <[EMAIL PROTECTED]> schrieb: > > <snip> > > > > Tja, es gibt aber durchaus Build-Systeme abseits der autotools. KDE wird > > > wohl fuers naechste Major auf CMake umsteigen (scons/bksys hat nicht > > > genug Unterstuetzung). > > > > > > Ansonsten sollte man vllt. mal ueberlegen: Wenn schon XML-Beschreibungen > > > wieso nicht ant nutzen? Oder maven?... > > > > Igitt (IMHO). Hast du schon einmal die build.xml eines größeren > > Projektes gesehen? Weißt du, wie viele Verrenkungen man für eine > > einfache 'for i in ...'-Schleife machen muss, damit ant das hinkriegt? > > for-Schleife ? Wozu das ?
In dem speziellen Fall übernimmt das build-Skript die Funktion des gettext-Makefiles und kümmert sich damit um die Internationalisierung eines Java-Programms bzw. der Dokumentation (mittels xml2po). Benötigt wird ant-contrib.jar. Rein theoretisch (und auch praktisch) lässt sich das Problem mit ant >= 1.6.5 allerdings auch implizit lösen (IIRC). Alternativ müssen Skripte diesen Part übernehmen. Weitere Anwendungen sind problemlos denkbar (vor allem im Bereich der Bedingten Anweisungen). Wenn es wirklich interessiert, nenne ich noch einige konkrete Beispiele. [snip] > > Aber da XML eben jedes Element beschreibt, kommt viel mehr > > Schreibaufwand als in der Makro-Sprache, die für die autotools > > benutzt wird, heraus (IMHO). > > Also an dem bissl. Schreibaufwand sollte eine saubere Modellierung > nicht scheitern - im Vergleich zum Programmcode ist das doch > ohnehin schon verschwindend ... Ich wollte deine Idee ja auch nicht kritisieren. Nur je größer und unübersichtlicher das Makefile wird, desto schlechter ist die Benutzbarkeit und die Fehlerträchtigkeit steigt ebenfalls. Das solltest du bei deiner Idee nicht vernachlässigen. Bei den autotools werden die aus den Makros erstellen configure/Makefile(.in) ja auch unübersichtlich. So gesehen, hat die Verwendung von Makros deutliche Vorteile. Was die Modellierung des Systems selbst angeht, kann ich nicht beurteilen. MfG Daniel
