* Eduard Bloch <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------
