Re: ein neues buildsystem --> autotools endlich abloesen

[Daniel Leidert <daniel.leidert.spam@gmx.net>]

Am Freitag, den 03.03.2006, 17:07 +0100 schrieb Enrico Weigelt:
> * Daniel Leidert <daniel.leidert.spam@gmx.net> schrieb:
> 
> <snip>
> > > 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). 
> 
> Ahso, Du hast also eine Menge an Sprachen, für die jeweils die 
> gleiche Struktur gibt. Damit Du nicht für jede Sprache alles 
> extra aufschreiben mußt, möchtest Du eine Aufzählung.

Exakter: Ich möchte die Kommandosequenz möglichst nur einmal schreiben
und auf eine Liste anwenden.

> Wir bräuchten also eine Notation, die aus einem Template und 
> einer Liste eine Reihe von Knoten macht. Vielleicht so ?
> 
>     <multilang languages="de en hu hr it">
> 	<i18n-po name="foo" />
>     </multilang>

Richtig. Das setzt Templates voraus, die die eigentliche Arbeit im
Hintergrund erledigen. Und mit einem solchen Template, müsstest du schon
die Bedürfnisse vieler Entwickler erfüllen. Dabei darfst du aber nicht
vergessen, dass sich z.B. die gettext-Unterstützung und die notwendigen
Befehle/Optionen unterscheiden können: So sähe ein Makefile, dass die
i18n-Unterstützung für eine QT-Applikation erledigt ganz anders aus, als
z.B. das Makefile für eine Java-Applikation oder eine einfache
C-Applikation (schau mal bei gettext-doc ins Beispieleverzeichnis) -
z.B. unterscheiden sich das Format und auch das Zielverzeichnis. Daneben
stehen ja noch Applikationen zur Verfügung (mit gettext als Backend), um
Formate zu internationalisieren, die nicht von gettext unterstützt
werden (xml2po, xml2pot, ...). Aber eigentlich bezog sich mein Beispiel
spezifisch auf ant.

> > Alternativ müssen Skripte diesen Part übernehmen. 
> 
> Sowas möchte ich nach Möglichkeit vermeiden.

Das erfordert dann aber, dass dein System entweder a) das ultimative
Template für eine Aufgabe enthält oder b) sehr flexibel die
Möglichkeiten zur Erstellung eines solchen Templates bereitstellt.

> > Weitere Anwendungen sind problemlos denkbar (vor allem im Bereich 
> > der Bedingten Anweisungen). 
> 
> Beispiele ?

In dem speziellen Fall (der sich wieder auf ant bezieht):

<condition property="History.uptodate">
  <and>
    <uptodate targetfile="build/doc/History/ChangeLog.html">
      <srcfiles dir="doc/source" includes="History.xml,HistoryToHtml.xsl,history/changes.xml" />
    </uptodate>
    <uptodate targetfile="build/doc/History/ChangeLog_fr.html">
      <srcfiles dir="doc/source" includes="History_fr.xml,JmolHistoryToHtml.xsl,history/changes_fr.xml" />
    </uptodate>
    <uptodate targetfile="build/doc/History/ChangeLog_nl.html">
      <srcfiles dir="doc/source" includes="History_nl.xml,JmolHistoryToHtml.xsl,history/changes_nl.xml" />
    </uptodate>
  </and>
</condition>

Und das gleiche dann noch für jedes Handbuch. Man erkennt vielleicht den
Aufwand, der bei steigender Zahl von Übersetzungen entsteht. Auch ein
typisches Beispiel, wo sich Listen einfacher machen. Und dann hast du
wieder das Problem: Entweder du stellst Schleifen zur Verfügung oder
stellst ein entsprechendes Template zur Verfügung. Da die Anwendung von
Listen sich aber wohl eher nicht einschränken lässt, wird wohl erstere
Lösung ein Muss sein. Sonst wird der Schreibaufwand unverhältnismäßig
hoch.

> <snip>
> 
> > 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. 
> 
> Ja, da muß man eben abwägen. Aber ich denke nicht, daß mein
> Modell zu überzüchtet ist, zumal es ja kein Problem darstellen
> dürfte, für einfachere Fälle eine schmalere Modellierung 
> zu wählen, aus der dann das XML-File generiert wird.

Das ist bis hierhin erst einmal nur eine Behauptung, denn deine
Implementierung fehlt ja noch ;)

> <snip>
> 
> > Bei den autotools werden die aus den Makros erstellen 
> > configure/Makefile(.in) ja auch unübersichtlich.
> 
> Die haben aber weder eine stabilen Syntax noch eine klare Modellierung,

Dem würde ich nicht zustimmen. Aber evtl. könntest du diese Aussage
näher erläutern.

> und der Code wird mit jeder weiteren Stufe unübersichtlicher.

Das wirst auch du nicht unterbinden können. Denn je größer die Anzahl
unterstützter Systeme wird, desto umständlicher werden wohl deine Tests
und Ausnahmen wohl auch ausfallen. Würden sich die autotools nicht um
eine so breite Unterstützung von Systemen bemühen, würden auch dort die
Makros weniger voluminös und strukturierter ausfallen. Das ist IMHO der
Preis für Flexibilität.

> Das
> Hauptproblem ist wohl, daß immer nur ein System über ein anderen
> als Macrosammlung dübergestülpt wurde, ohne daß die Syntax in 
> sich abgeschlossen ist - sozusagen ist automake ein Dialekt von make.

Ok. Das ist bestimmt richtig. Um wirklich mit den autotools umgehen zu
können (und auch nocht normgerecht zu schreiben), kommst du um die
Kenntnis von automake, autoconf, make und m4 nicht herum. Allerdings
empfinde ich das persönlich nicht als sooo tragisch.

PS: Evlt. entwickelst du zuerst einmal dein Modell und dann lohnt die
Diskussion erst wirklich. Alles falsch machen, können die autotools ja
nicht, sonst würde sie nicht in der breiten Masse eingesetzt werden.

MfG Daniel