Re: ein neues buildsystem --> autotools endlich abloesen
* Eduard Bloch <edi@gmx.de> schrieb:
<snip>
> > Also so langsam ist java bei dieser Problemklasse nicht (und sicher
> > nicht langsamer als shellscript oder perl), zumal der Anteil Rechenzeit
> > im Buildsystem gegenüber dem der Toolchain verschwindend sein düfte.
>
> Weil du keine Tests der Systemumgebung machst sondern eine perfekte
> Grundkonfiguration erwartest.
Richtig, genau das ist der Knackpunkt:
Ich *erwarte* daß das System gewisse Vorraussetzungen erfüllt.
Wenn eine bestimmte Schnittstelle vorhanden ist, muß sie auch
korrekt sein, ansonsten gilt sie als nicht vorhanden.
Dazu muß man natürlich auch hinreichend fein granulieren
(POSIX ist da zu allgemein), zB. einzelne Kernel-Features wie
BSD-Sockets:
Entweder kann mein System das - dann steht das entsprechende Flag
im System-Profil auf 1 - oder eben nicht, dann stehts auf 0.
Wenn das System nur eine Buggy-Implementation hat, dann hat es
keine. Vielleicht findet sich dann jemand, der das entweder
korrigiert (bei closed-source nicht immer so einfach) oder einen
workaround in der libc versteckt - danach kann das Flag auf 1
gehen und jeder weiß, daß wir jetzt auch BSD-Sockets haben ...
Sicherlich muß irgentjemand diese System-Profile pflegen, aber
nicht jede einzelne Anwendung. Das kann entweder ein Programm machen
(hier könnte evtl. sogar wieder autoconf verbacken werden) oder
ein Mensch - das liegt aber alles nicht mehr im Verantwortungs-
Bereich des Anwendungsentwicklers. (genauso wie es nicht dessen
Aufgabe ist, für einen funktionierenden C-Compiler zu sorgen).
<snip>
> Das mag vielleicht auf einem ordentlich verwalteten System funktioniert
> (siehe Debian-Policy, shlibs/netlibs u.ae. Mechanismen, pkg-config etc.),
> aber in der Wildniss sieht es nicht immer so rosig aus. Ansonsten
> verweise auf die ausfuehrliche Kritik von Andreas.
Dann muß die Wildniss eben korrigiert werden.
Man kann nicht jedem einzelnen Anwendungsentwickler nicht die Verantwortung
für die Fehler des Betriebssystems oder einzelner Libs aufbürden.
Das ist vorallem mal Verschwendung von wertvollen Resourcen.
<snip>
> Fuer eine "ordentlich konfigurierte" Umgebung reicht aus ein normales
> Makefile, das ordentlich Gebrauch von `pkg-config ...` macht.
Theoretisch ja. Man könnte auch das von mir vorgeschlagene Verfahren
mit den System-Profilen in Makefiles nutzen. So könnte man durchaus
auch libc- oder Kernel-Features, wie zB. o.g. BSD-Sockets hitner
pkg-config verstecken. Das halte ich sogar für sehr sinnvoll.
Aber viele andere Sachen, die mit meiner Modellierung möglich sind,
wären mit Makefiles wenn dann nur schwer bzw unübersichtlich
machbar, zB.:
+ schaltbare Features (bei autoconf --enable-foo/disable-foo)
+ relocations (wohin soll was installiert werden)
+ Paketunterteilungen (zB. nach Sprachen, etc)
+ individuelle Link-Configurationen (zB. Apache-Module, etc)
Mir persönlich behagen aber einige Prinzipielle Dinge an make nicht:
Es modelliert nicht die Struktur der Software, sondern Regeln um
diese zu bauen. Damit kontrolliert der einzelne Paket-Autor die
Abläufe, wie seine Software gebaut wird, anstatt das einem anderen
System - das dann nämlich bei Bedarf ganz fein an die Ziel-Plattform
angepaßt werden kann - zu überlassen. Und genau da will ich hin.
<snip>
> > > Java ist so abstrahiert dass es sich nur über Umwege für systemnahe
> > > Programme einsetzen laesst.
> >
> > Was genau verstehst Du unter "systemnah" ?
>
> Wie ich schon sagte, snip nicht alles wichtige weg.
> Mein Java ist zur Zeit etwas angestaubt, aber IIRC fehlten da
> grundsaetzliche Dinge wie globales chdir und auslesen der
> Systemvariablen.
Okay, auf (natives) chdir kann man verzichten, weil AFAIK das exec
eh über die Shell läuft (so jedenfalls meine Erfahrung mit kaffe)
- man packt einfach "cd <dir> &&" vor das eigentliche Kommando.
Env-Zugriff fehlt aber in der Tat :(
Ich hab mir aber mit einer kleinen Klasse ausgeholfen, die einfach
env aufruft und das Ergebnis in einer Properylist reinparst.
(müßte dann evtl. für nicht-Unix angepaßt werden)
<snip>
> > > Ich sehe nicht ein, warum ich für die Arbeit, die ein Shell- oder
> > > Perl-Einzeiler erledigt plötzlich einen neuen Monster brauche.
> >
> > Ich bezweifle, daß sich diese Aufgabe in einem Perl-Einzeiler
> > lösen läßt (nein, 100k-Zeilen oder selbstgeschriebene perl-
> > extensions werden nicht gewertet ;-))
>
> Sorry, aber da sind grundlegende Dinge, die man in den genannten
> Sprachen sehr effizient loesen kann - globs (shell pattern), einfaches
> Einlesen der Programmausgaben u.ae. Das sind Dinge, die du _brauchst_,
> sobald das Build-System an besondere Gegebenheiten angepasst werden muss
> (die bei dir wohl nicht in der UseCase-Menge auftauchen), ansonsten legt
> das Build-System eher Steine in den Weg.
Nenn doch bitte mal ein paar Beispiele.
<snip>
> Aber irgendwie liegen meine Anforderungen sowieso etwas anders. Du hast
> von Anfang das anders geplannt und hast die Flexibiliaet zusammen mit der
> "unnoetige Turing-Vollstaendigkeit" in eine Schublade gesteckt. Insofern
Zugegeben bin ich da ein wenig fundamentalistisch - aber das mit
voller Absicht: meine Erfahrung des letzten Jahrzehnts in der OSS
hat mir gezeigt, daß viele "Eigenheiten" in den einzelnen Paketen
nicht nötig bzw. nicht sinnvoll sind und leicht substituiert
werden können. Viele erübrigen sich bei konsequenter Verschlankung
der Strukturen (siehe oben: knallharte Vorraussetzungen statt
Wuchern lassen von Einzelfällen) selbst erübrigen.
> > Londo: "ah ... Lyta Alexander, as you live and breathe ..."
> > Lyta: "I suggest you remove your hand, Ambassador, or you will
> > do neither for much longer ..."
>
> Hm... aus The Gathering ist es IMO nicht.
3x04 - passing through Gethsemane
BTW: hast Du vielleicht eine einigermaßen vollständige Sammlung ?
Meine ist noch recht Lückenhaft, insbesondere in dem Bereich
Kriegsrecht -> Unabhängigkeitserklärung.
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: