Re: ein neues buildsystem --> autotools endlich abloesen
* Eduard Bloch <edi@gmx.de> schrieb:
<snip>
> Und womit willst du diese Leute motivieren?
Warum immer ich ?!
Ich programmiere das Tool, weil ich es für richtig halte, und ich
portiere die für mich wichtigen Pakete darauf, weil ich es für
richtig halte.
Ansonsten biete ich jedem Interessiertem an, die Software selbst
einzusetzen und ggf. mitzuarbeiten. Ich muß niemanden überzeugen
oder missionieren, bin doch kein Christ.
<snip>
> Sicherlich kann man eine VM voraussetzen, aber Java ist einfach zu
> weltfremd (oder systemfremd) und hebt sich zu weit von POSIX ab.
Definiere "weltfremd".
<snip>
> > Welche brauchst Du denn ?
>
> Wie gesagt, AIX4.3?
Du darfst gern mitmachen und Dich um das AIX-Port kümmern.
<snip>
> > Ja und ? Wo ist jetzt das Problem ?
> > Dafür gibts conditionals, mit dem sich einzelne optionale Features
> > modellieren lassen.
>
> Wer soll diese Arbeit machen?
Welche Arbeit ? Der Aufwand ist geringer, als automake-files zu
schreiben.
<snip>
> vernünftigen flexiblen Script-Sprache in das Build-System, das kann man
> von Java nicht behaupten (oder seit wann gibt es System.chdir?).
Wenn Dir an Java irgentetwas nicht paßt, kannst's auch gerne in
einer anderen Sprache programmieren. Ich produziere ledeglich die
Referenzimplenentation in Java.
Das Entscheidende ist die Modellierung, nicht die Implementation.
<snip>
> 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.
Dein Pecht. Du mußt es nicht nutzen.
Sie oben: ich bin kein Christ, ich muß Dich nicht missionieren.
<snip>
> > 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.
Muß man nicht, und sollte man auch nicht. Besser das Problem an
der Wurzel packen.
<snip>
> Im Prinzip ja... aber viele DAUs (oder meinetwegen schlecht motivierte
> Lernende) versuchen es trotzdem, stell dich schon mal auf viel
> Support-Arbeit ein.
DAUs sind (an dieser Stelle) irrelevant.
(es sei denn sie legen Geld auf den Tisch ;-))
<snip>
> > "Schwierig" ist arg untertrieben. Autotools ist pure Schlamperei,
> > schon konzeptionell.
>
> Yep. Aber sind relativ erfolgreich.
Historisch bedingt. Menschlinge neigen dazu, sich an althergebrachte
Dinge zu klammern, auch wenn sie noch so miserabel sind. Das macht sich
ja auch an der Verbreitung verschiedener Religionen zeigen ...
<snip>
> Ich würde sie auch gerne aus der Welt schaffen, aber nicht mit einer
> Java/XML-Kracke ersetzen.
Definiere bitte den Zusammenhang zwischen Java, XML und Kacke.
<snip>
> Und Java wäre vielleicht noch akzeptabel mit ein Paar Workarounds,
> aber dann geht gcj leider nicht überall.
Wo genau hast Du ein Problem mit java ?
Ansonsten ist erstmal nur die Referenzimplementation in Java
geschrieben. Die dürfte dann aber bei fortschreitender Portierung
nur 30% des gesamten Codes ausmachen.
Wichtig ist vorallem die grundlegende Modellierung und die Profile
für die einzelnen Zielplattformen.
Wem die Referenzimplementation nicht paßt, der darf es gern
in einer beliebigen anderen Sprache nachprogrammieren.
Es gibt ja auch unzählige httpd-Implementationen ...
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: