Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> > Ich werde erstmal eine ganze Reihe Anwendungen (zB. Xorg-mod) portieren.
> > Dann müßt ich erstmal genug Fallbeispiele haben, um die wichtigsten
> > Systemgegebenheiten zu berücksichtigen.
>
> Auf allen Architekturen/Plattformen auf die sie jeweils laufen koennen?
Nein, nur jene die mich interessieren. Um weitere können sich dann
gern andere Leute kümmern ... autotools sind ja auch nicht von
einem allein gecoded.
Welche brauchst Du denn ?
<snip>
> > Wer dann noch weitere Fälle berücksichtigt werden sollen, dann muß
> > das eben mit dem Gremium abgestimmt werden.
>
> Das wird ein no-go sein. IMHO muss ein Buildsystem vom Entwickler
> erweitert werden koennen wenn sich neuere Anforderungen ergeben.
Wieviele Anwendungen hast Du schon programmiert ?
<snip>
> Wenn zum Beispiel eine neue Bibliothek erscheint und eine Applikation
> Y diese optional einbinden moechte.
Ja und ? Wo ist jetzt das Problem ?
Dafür gibts conditionals, mit dem sich einzelne optionale Features
modellieren lassen.
<snip>
> Oder wenn sich bestimmte Dinge in einer
> Abhaengigkeit aendern auf die man testen will/muss.
Beispielsweise ?
<snip>
> > Als Anwender muß man eben damit rechnen, daß man immer die neueste
> > Version des Buildsystems installieren muß. Auf Veraltetes kann keine
> > Rücksicht genommen werden.
>
> Erklaer das mal den Leuten die Debian stable einsetzen wollen, aber
> trotzdem z.B. von Spamassassin aktuellere Versionen bauen.
Nicht meine Baustelle. Ich bin kein Debian-Maintainer.
<snip>
> > > s.o. Wie siehts mit der Erweiterbarkeit aus?
> >
> > Gibt es per Definition nicht. Wenn neue Knotentypen benötigt werden,
> > muß das Buildsystem weiterentwickelt werden. Als Programmierer sollte
> > man sich bemühen, mit dem auszukommen, was geboten wird.
>
> Der war gut. Wenn ich eine Applikation entwickle entscheide ich mich
> fuer eine bestimmte Menge an Abhaengigkeiten. Diese Abhaengigkeiten
> koennen sich aber ueber die Zeit veraendern, das heisst entweder muss
> ich _immer_ auf die zur Entwicklung benutzte Version der
> Bibliothek/anderen App dependen oder aber ich nehme ein erweiterbares
> Buildsystem.
Was haben die Dependencies Deiner Anwendung mit der Version meines
Buildsystems zu tun ? Willst Du etwa einzelne Paketinfos im Buildsystem
hardcoden ?!
Ich versteh grad Dein Problem nicht.
<snip>
> Wie wird das mit CVS/SVN-Versionen von Bibliotheken ohne
> klare Versionsnummer funktionieren?
Jede Library braucht eine klare Versionsnummer. Man erhöht sie einfach
direkt nach jedem Release. Ich sehe kein Problem darin, wenn verschiedene
(minor-)Revisionen sich die gleiche Versionsnummer teilen - von jemanden
der direkt vom CVS zieht, darf man beruhigt erwarten, daß (er|sie|es)
weiß, was (er|sie|es) tut ...
> > Richtig. Es werden klare Interfaces definiert (zB. BSD-sockets), die
> > entweder vorhanden sind oder fehlen. Ein Paket kann das nun entweder
> > vorraussetzen (require) oder verzweigen (conditional). Aber es kann
> > nicht so weitergehen, daß jeder irgentwelche Hacks produziert,
> > die irgentwas zu erraten versuchen und mehr schlecht als recht
> > funktionieren.
>
> Und wer soll die "Milliarden" moeglichen "Checks" maintainen?
Woher genau nimmst Du die Milliarden ? Ich sehe nur wenig mehr als
hundert. Ansonsten sehe ich auch nicht, was Du checken willst -
wir orakeln nicht rum, wir *definieren*.
<snip>
> Ich sehe durchaus ein, dass es schwierig ist wenn Hinz und Kunz ihre
> eigenen Makros definieren die nur auf dem eigenen System funktionieren.
"Schwierig" ist arg untertrieben. Autotools ist pure Schlamperei,
schon konzeptionell.
> Aber das hat meistens einen entscheidenden Einfluss auf die (Nicht-)
> Akzeptanz solcher Applikationen.
Das ist *mir* persönlich relativ egal. *Ich* portiere jene Pakete,
die *mich* interessieren, und ich würde freuen, wenn andere ihre
Pakete portieren. Aber wem das nicht paßt, der soll entweder
konkrete Verbessungsvorschläge bringen oder dezent meine Arbeit
ignorieren und seine Klappe halten.
<snip>
> > Noch nicht. Aber da ich nur die grundlegenden Funktionen verwende
> > (keine GUI, keine templates, etc) und überhaupt der Code recht
> > schmal ist, sollte das kein Problem darstellen.
>
> Ich glaube kaum das das so bleiben wird (also das mit dem schmalen
> Code).
Die wesentlichen Strukturen stehen. ca. 200kb source.
Wenn im fertigen System vielleicht 1MB rauskommen, dann ist das
immernoch im grünen Bereich. Ansonsten ist "schmaler Code"
mehr eine Frage des sauberen Designs, statt nur der reinen Quantität.
<snip>
> > Ja. Das ist nicht ganz trivial. Besonders beim X-server wirds
> > spannend - der läßt sich so schon kaum compilieren ...
>
> :-) Ich hab X.org 6.8 bisher 1x kompilieren koennen und das war schon
> ein Krampf...
Das war wohl noch der monolithische Baum mit imake - eine andere Welt.
Mit der Modularisierung ist schon vieles besser geworden, auch wenn
man mit vanilla-autotools schnell mal gegen die Wand fährt.
> Aber nur zu, wenn dein System mal was "kleineres" bauen kann (eine
> KDE-App) schau ich mir das vllt. trotzdem mal an.
KDA-Apps würde ich nicht als "klein" bezeichnen, außer vielleicht
im Vergleich zum Openoffice ...
Ansonsten ist für mich fehlkonzipierte Software keine Referenz.
<snip>
> PS: Nimm mir meine Kommentare nicht uebel, ich nehme immer alles
> auseinander, hab schon mit 3 Jahren damit angefangen ;-)
Kannst Du auch etwas wieder zusammenbauen ?
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: