Re: ein neues buildsystem --> autotools endlich abloesen
* Daniel Leidert <daniel.leidert.spam@gmx.net> schrieb:
<snip>
> > 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.
Verabschiede Dich bitte von Dem Begriff "Kommandosequenz".
Kommandos gehen Dich hier nichts mehr an - Du gibts ledeglich die
*Struktur* vor - welche Kommandos daraus folgen, ist ausschließlich
Sache des Buildsystems.
<snip>
> > 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.
Genau. Wobei ich das meiste wohl erstmal durch fest programmierte
Nodetypes erledigen werde.
<snip>
> 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.
Darum kümmert sich dann der entsprechende Nodetype. Allenfalls gibt
man ihm noch einen Parameter für das benötigte Ausgabeformat an.
<snip>
> 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.
Auch das erledigt der Nodetype: er kümmert sich selbst darum, aus
der gegebenen Quelle das gewünschte Ziel zu erzeugen, die dazu
nötigen Befehle auszuführen.
<snip>
> > > 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.
hmm, ich bin für einen Kompromiß aus beiden.
Ich denke aber, daß es in >90% der Fälle kein Problem darstellen
wird - die restlichen 10% sind ohnehin so kompliziert, daß man
mit einem generellen Buildsystem, gleich welcher Art, nicht viel
weiter kommt.
<snip>
> > > 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.
hmm. erstmal würd ich das dahingehend einschränken, daß der
locale-name immer im Filenamen steckt, und en keine Ausnahme macht.
Dann vielleicht (mit eigenem Nodetype) so:
Ansonsten ist mir auch noch nicht ganz Klar, warum Du die Aktualität
irgentwelcher Files innerhalb des Paketes in einer Condition
verbacken willst. Um das neu-Erzeugen veralteter Files kümmert sich
doch das Buildsystem allein.
<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.
Das Problem an automake ist doch, daß es iW. eine Macro-Sammlung zum
Bauen von Makefiles ist. Ergo kann ich - unter gewissen (IMHO nicht
sonderlich klar definierten) Einschränkungen - in den Source-Files
eigene Makefile-Rules packen. Desweiteren erzeugt es automatisch
(und IMHO wiederum ungenügend definierten Wege) aus einzelnen
Variablendefinitionen eine riesige Menge an macros und ein gigantisches,
nicht debuggbares shell-script.
Für einfache Fälle, zB. eine einfache lib, evtl. mit einfachen
Conditions, ist das alles recht gut beherrschbar. Da braucht man aber
keine Make-Syntax, sondern nur eine flache Textdatei, wo ein paar
Attributes und Files gelistet sind, und man als Programmierer nur
wenige (nicht vollautomatisch entdeckbare) Fehler machen kann.
Komplexere Dinge brauchen dann wieder die Kenntnis der Make-Syntax,
aber oft auch eine hinreichend genaue Kenntnis der automake-Interna,
da ja schließlich eine nicht unerhebliche Menge an Makefile-Code
erzeugt wird. Dort ist die Menge an Fehlermöglichkeiten sehr groß.
Das halte ich nicht für eine stabile und überschaubare Syntax.
Evtl. magst Du ja mal bei einer Reihe größerer/komplexerer
Projekte in den Maillinglisten recherchieren, wieviel dort über
Hacks und Flickereien mit automake diskutiert wird. IMHO alles
verschwendete Lebenszeit.
<snip>
> > 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.
Nein. Ihre Zahl erhöht sich vielleicht, aber nicht die Komplexität.
Mein System testet nicht, es fragt eine Datenbank. Diese wird auf eine
geeignete Weise gepflegt - sei des automatisch oder manuell, aber das
ist nicht mehr Aufgabe des eigentlichen Builsystems (sondern allenfalls
desssen Installationssystem).
> 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.
Der Preis zu lascher Organisation, IMHO.
Es wird dort versucht, auf jeden feuchten Pfurz, sowohl im Zielsystem
als auch im Paket, rücksicht zu nehmen, ohne man eine harte Linie
reinzubringen. Das mündet zwangsläufig in einer unherrschbaren
Komplexität. Erstmal muß unnötige Komplexität vermieden werden,
bevor man sich um weitere Features kümmern kann. Sonst enden wir
irgentwann bei Zuständen wie in den deutschen Verwaltungen ...
<snip>
> > 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.
Ich empfinde das als sehr tragisch. Ich will eigentlich nur die
relevanten Informationen über mein Paket, in einer möglichst
kurzen und übersichtlichen Form, aufschreiben. Den Rest soll das
Buildsystem allein erledigen. Schließlich will ich mich auch nicht
um die Interna des Compilers kümmern müssen.
<snip>
> 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.
Ich entwickle ja erstmal das Modell (anhand von vielen Praixbeispielen)
und baue dann stück für Stück die Referenzimplementation.
Wenn es Dich interessiert, kann ich's ja mal ins CVS packen und Dir
Zugriff geben.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service
phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Reply to: