Re: ein neues buildsystem --> autotools endlich abloesen
#include <hallo.h>
* Enrico Weigelt [Sat, Mar 04 2006, 02:45:44PM]:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > > 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.
Und womit willst du diese Leute motivieren? Shell, Perl und Make sind
praktisch Basiswerkzeuge jeder unixoiden Plattform. Java dagegen kaum.
Sicherlich kann man eine VM voraussetzen, aber Java ist einfach zu
weltfremd (oder systemfremd) und hebt sich zu weit von POSIX ab. Da
haben die "natürlichen" Skriptsprachen, einen weiten Vorsprung -- und
sag jetzt nicht "import POSIX;", das sind Workarounds.
> Welche brauchst Du denn ?
Wie gesagt, AIX4.3?
> > > 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 ?
Wenn du schon so anfängst - wieviel Text hast du schon mal geschrieben
(Stichwort: Plenken).
> > 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.
Wer soll diese Arbeit machen? Du stellst es dir zu einfach vor, du
findest nicht für jede Aufgabe den richtigen Freiwilligen mit den
richtigen Skills. S.o., sehr motivierend ist der Gewinn nicht. Und
Konkurenz gibt es ebenfalls auf dem "Markt" (Ant, SCons), die raufen
sich alle um Manpower. Gerade SCons integriert die Macht einer
vernünftigen flexiblen Script-Sprache in das Build-System, das kann man
von Java nicht behaupten (oder seit wann gibt es System.chdir?).
> > > 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.
Dir ist schon klar, dass revolutionäre Entwicklung Jahre brauchen, um
sich zu setzen? Ich kann (nicht nur als Maintainer) deine Haltung
natürlich verstehen, aber sie in diesem Kontext nicht unterstützen.
> > 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.
Er meint vielleicht Workarounds, die man für diverse kaputte Umgebungen
bauen muss. Oder so.
> > 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 ...
Im Prinzip ja... aber viele DAUs (oder meinetwegen schlecht motivierte
Lernende) versuchen es trotzdem, stell dich schon mal auf viel
Support-Arbeit ein.
> > 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.
Yep. Aber sind relativ erfolgreich. Ich würde sie auch gerne aus der
Welt schaffen, aber nicht mit einer Java/XML-Kracke ersetzen. Und Java
wäre vielleicht noch akzeptabel mit ein Paar Workarounds, aber dann geht
gcj leider nicht überall.
> > 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.
Ack. Aber eine Feststellung der Tatsachen darf man ja wohl noch machen.
MfG,
Eduard.
--
Es gibt Leute, die nehmen das ernst.
-- Klaus Knopper (über die fortunes)
Reply to: