Gibt es Frameworks für Unix-Tools?
Egon Schmid
gemeinsam.
Bei der Installation:
=====================
Mit "sh configure [OPTIONS]" oder "./configure [OPTIONS]" wird das
System analysiert und ein Makefile generiert.
Danach kann man mittels "make install" die Software installieren.
Der Befehl selbst:
==================
Jeder Befehl wertet erst mal die Argumente aus.
Dabei haben sich manche Argumente standardisiert.
--help (manchmal -h oder beides):
gibt eine Hilfe-Seite mit Liste der Optionen aus.
Manche Programme berï¿œcksichtigen sogar die locale-Einstellungen.
Lustig:Bei mir gibt "grep --help" den Text teils deutsch, teils
englisch aus: :)
--version :
gibt die Versionsnummer aus
Gibt es Frameworks, mit denen man so Shell-Tools schnell erstellen kann?
Frameworks sind so Grundgerï¿œste, bei denen viele Funktionen und Ablï¿œufe
schon zur Verfï¿œgung stehen oder diese stark vereinfacht werden.
Das Ziel von Frameworks ist, dass man nicht alles neu programmieren
muss, und Programmcode teils 1:1 wiederverwenden kann.
Der Nachteil von Frameworks ist jedoch, dass die Programme oft langsamer
sind und mehr RAM benï¿œtigen.
So kï¿œnnte es beispielsweise eine Funktion "registerOption" geben mit den
Argumenten:
- char * bzw. String option -> Die Option, z.B. "--version"
- char * shortcut -> das Kï¿œrzel, z.B. -v
- char * infotext -> Der Infotext, der bei "--help" erscheint
- function callback -> eine Callback-Funktion, die bei Angabe der Option
aufgerufen wird
Gibt es solche Frameworks fï¿œr Shell-Commands, eventuell auch fï¿œr
Daemons? Daemons haben ein Config-File unter /etc/ und besitzen auch
meist einen Listen-Port, welcher in diesem Config-File angegeben werden
kann.
Grￜￜe
Egon Schmid
Felix Palmen
> Es gibt gewisse Dinge, die haben (fast) alle Unix-Pakete/Programme
> gemeinsam.
>
> Bei der Installation:
> =====================
> Mit "sh configure [OPTIONS]" oder "./configure [OPTIONS]" wird das
> System analysiert und ein Makefile generiert.
>
> Danach kann man mittels "make install" die Software installieren.
GNU Autotools. Die sind ein bisschen problematisch zu erlernen, aber
wenn man sich erstmal zurechtfindet (und so halbwegs die nicht ganz
geläufige Makrosprache M4 kapiert hat) sind die sehr hilfreich, vor
allem wenn es um maximale portabilität des Build-Systems geht.
Hilfreiche Einführung z.B. hier:
<http://sourceware.org/autobook/autobook/autobook.html>
[Ergänzung: Nimm auf jeden Fall ein Build-System das Makefiles erstellt,
die bei der Installation DESTDIR verstehen, das erleichtert es ungemein,
deine Software auch einmal zu paketieren (.deb, .rpm). GNU Autotools
sind in der Hinsicht geeignet.]
Alternativen gibt es natürlich auch, hier ist glaube ich vor allem cmake
bekannt.
> Der Befehl selbst:
> ==================
>
> Jeder Befehl wertet erst mal die Argumente aus.
> Dabei haben sich manche Argumente standardisiert.
>
> --help (manchmal -h oder beides):
> gibt eine Hilfe-Seite mit Liste der Optionen aus.
> Manche Programme berücksichtigen sogar die locale-Einstellungen.
>
> Lustig:Bei mir gibt "grep --help" den Text teils deutsch, teils
> englisch aus: :)
>
> --version :
> gibt die Versionsnummer aus
>
> Gibt es Frameworks, mit denen man so Shell-Tools schnell erstellen kann?
Nicht exakt was du suchst, aber vielleicht hilft dir die popt library
weiter.
Grüße,
Felix
--
Felix Palmen (Zirias) + [PGP] Felix Palmen <fe...@palmen-it.de>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683
Sven Geggus
> Gibt es solche Frameworks für Shell-Commands, eventuell auch für
> Daemons?
Sowas?
http://wsd.iitb.fhg.de/~geg/clighome/
Sven
--
"and on the third day he rebooted into Linux-1.3.84"
(Linus Torvalds, Easter Kernel Release 1996)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
Volker Birk
> So könnte es beispielsweise eine Funktion "registerOption" geben mit den
> Argumenten:
> - char * bzw. String option -> Die Option, z.B. "--version"
> - char * infotext -> Der Infotext, der bei "--help" erscheint
> - function callback -> eine Callback-Funktion, die bei Angabe der Option
> aufgerufen wird
> Daemons?
Frameworks sehe ich da nicht, aber es gibt z.B. GNU getopt für obigen
Zweck, siehe man getopt_long. Falls Du Scripten willst, gibt's z.B.:
http://docs.python.org/library/argparse.html
Viele Grüsse,
VB.
--
Bitte beachten Sie auch die Rückseite dieses Schreibens!
Juergen Ilse
Egon Schmid <egon....@dischingen.de> wrote:
> Es gibt gewisse Dinge, die haben (fast) alle Unix-Pakete/Programme
> gemeinsam.
>
> Bei der Installation:
> =====================
> Mit "sh configure [OPTIONS]" oder "./configure [OPTIONS]" wird das
> System analysiert und ein Makefile generiert.
Das hast du nur bei autoconf oder aehnlichen Systemen. Es geht auch
anders (und dieses "andere" ist gAr nicht mal so selten).
> Danach kann man mittels "make install" die Software installieren.
Wenn man schon make fuers compilieren verwendet, bietet es sich an,
die Installation ebenfalls damit durchzufuehren. Aber auch da gibt es
(allerdings seltener) auch Ausnahmen von ...
> Der Befehl selbst:
> ==================
> Jeder Befehl wertet erst mal die Argumente aus.
Falsch. Die shell wertet die Parameter aus und startet das Programm mit
den bereits ausgewerteten Parametern. Das ist ein erheblicher Unterschied
zu dem, was du dort oben geschrieben hast. Da fast jedes unixoide System
eine unix-shell mitbringt, ist es nicht weiter verwunderlich, dass solche
Systeme in dem Punkt uebereinstimmen (wenn auch nicht ganz so wie du es
dort oben geschrieben hast).
> Dabei haben sich manche Argumente standardisiert.
Die GEmeinsamkeiten halten sich da eher *sehr* in Grenzen ...
> --help (manchmal -h oder beides):
"--help" ist (wie fast alle "langen Optionen") eine Spezialitaet der
"GNU-Tools", ansonsten sind sie eigentlich eher Seltenheit. Bei den
"althergebrachten" unix-Kommandos findet man so etwas praktisch ueber-
haupt nicht.
Und "-h" hat bei einer Reihe von Kpommandos eine Bedeutung, die nicht
das geringste mit "Hilfe" zu tun hat ("du" sei als Beispiel erwaehnt).
Selbst von der Regel, dass Optionen mit einem "-" beginnen gibt es
Ausnahmen (man denke an "tar") ...
> gibt eine Hilfe-Seite mit Liste der Optionen aus.
Bei weitem nicht immer.
> Manche Programme berücksichtigen sogar die locale-Einstellungen.
> Lustig:Bei mir gibt "grep --help" den Text teils deutsch, teils
> englisch aus: :)
Das wuerde ich als Bug ansehen.
> --version :
> gibt die Versionsnummer aus
Eine der "langen Optionen", die man im "althergebrachten unix"
praktisch *nirgends* findet.
> Gibt es Frameworks, mit denen man so Shell-Tools schnell erstellen kann?
Ein Teil der von dir beschriebenen Funktionalitaet ist keine Funktion
des jeweiligen Tools sondern der shell (siehe oben), ein weiterer Teil
laesst sich mit geringem Aufwand mittels der C-Library implementieren
(z.B. unter BEnutzung von "getopt".
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Felix Palmen
>> Der Befehl selbst:
>> ==================
>> Jeder Befehl wertet erst mal die Argumente aus.
>
> Falsch. Die shell wertet die Parameter aus und startet das Programm mit
> den bereits ausgewerteten Parametern. Das ist ein erheblicher Unterschied
> zu dem, was du dort oben geschrieben hast. Da fast jedes unixoide System
> eine unix-shell mitbringt, ist es nicht weiter verwunderlich, dass solche
> Systeme in dem Punkt uebereinstimmen (wenn auch nicht ganz so wie du es
> dort oben geschrieben hast).
Nicht falsch. Eine widerliche Unsitte, überall erstmal "falsch"
dranzupappen, auch wenn es lediglich eine Frage von Definitionen und
Standpunkten ist.
Was die Shell immer tut, ist die Parameter zu zerlegen, so dass das
Programm sie in einem array bekommt. Danben gibt es Funktionen wie die
evaluierung von shell-variablen und -ersetzungen, globbing, usw. Das ist
schön und gut, und JA, man kann das mit einem gewissen Recht "auswerten"
nennen.
Trotzdem muss das Programm seine Argumente auswerten. NACHDEM die Shell
ihre Arbeit geleistet hat. Das bedeutet hauptsächlich jedem einzelnen
Argument seine Bedeutung zuzuordnen; bei der häufig anzutreffenden
Schreibweise "--option parameter" oder gar "-ABC parameterA parameterB
parameterC" kann dafür durchaus auch ein Grammatik notwendig sein. DAS
ist die Auswertung, die für das Programm relevant ist, und es ist
zweifelsohne die, die der OP gemeint hat.
Juergen Ilse
Felix Palmen <fe...@palmen-it.de> wrote:
> * Juergen Ilse <jue...@usenet-verwaltung.de>:
>>> Der Befehl selbst:
>>> ==================
>>> Jeder Befehl wertet erst mal die Argumente aus.
>>
>> Falsch. Die shell wertet die Parameter aus und startet das Programm mit
>> den bereits ausgewerteten Parametern. Das ist ein erheblicher Unterschied
>> zu dem, was du dort oben geschrieben hast. Da fast jedes unixoide System
>> eine unix-shell mitbringt, ist es nicht weiter verwunderlich, dass solche
>> Systeme in dem Punkt uebereinstimmen (wenn auch nicht ganz so wie du es
>> dort oben geschrieben hast).
>
> Nicht falsch. Eine widerliche Unsitte, überall erstmal "falsch"
> dranzupappen, auch wenn es lediglich eine Frage von Definitionen und
> Standpunkten ist.
>
> Was die Shell immer tut, ist die Parameter zu zerlegen, so dass das
> Programm sie in einem array bekommt.
Die shell macht viel mehr: sie ersetzt Environment-Variablen, fuehrt
"command-substitution" aus, kuemmert sich um evt. vorhandene Ein-
und/oder Ausgabeumlenkungen, macht wildcard-expansion, ...
Der groesste Teil dessen, was sich ein "unix-Anfaenger" unter "Parameter-
Auswertung" vorstellen wird, wird von der shell ausgefuehrt und nicht
vom Programm, dass von der shell aufgerufen wird.
> Danben gibt es Funktionen wie die
> evaluierung von shell-variablen und -ersetzungen, globbing, usw. Das ist
> schön und gut, und JA, man kann das mit einem gewissen Recht "auswerten"
> nennen.
Es ist der groesste Teil der "Kommandozeilenauswertung".
Erich Fruehstueck
Niemand bestreitet, das die Shell ihre Kommandozeilen aufbereitet. Das
ändert aber nichts daran, dass die Aussage
"Jeder Befehl wertet erst mal die Argumente aus."
richtig ist. Ob jetzt das Element "-xa" des Argumentvektors die Option
"x" mit Parameter "a", die die zwei Optionen "x" und "a", der Parameter
"-xa" oder ein Syntaxfehler ist, entschiedet einzig das Programm selbst.
Für diese Entscheidung ist eine Auswertung notwendig (Ausnahmen sind
Befehle, die keine Argumente berücksichtigen oder die Argumente nur in
einer sehr trivialen Form nutzen).
Abgesehen davon, muss ein Befehl nicht von einer Shell aufgerufen
werden. Es gibt schließlich die Funktionen exec und co. Wie der
Argumentvektor zusammengestellt wird (mit command-line extension einer
Shell oder Elementar über eine String-Liste) ist aus der Sicht des
Befehls irrelevant.
Grüße, Erich
--
EFEU 3.2 is released!
Get the open source from http://efeu.cybertec.at.
Juergen Ilse
Erich Fruehstueck <ef....@aon.at> wrote:
> Am Sun, 24 Oct 2010 01:09:40 +0000 schrieb Juergen Ilse:
>> Es ist der groesste Teil der "Kommandozeilenauswertung".
> Niemand bestreitet, das die Shell ihre Kommandozeilen aufbereitet. Das
> ändert aber nichts daran, dass die Aussage
>
> "Jeder Befehl wertet erst mal die Argumente aus."
>
> richtig ist.
Woher weisst du von "jedem Befehl" dass er "erst mal die Argumente aus-
wertet"? Wenn die Kommandozeilenparameter (z.B. Dateinsmen) sequentiell
abgearbeitet werden, werden sie evt. von jenem Befehl jeweils erst dann
ausgewertet, wenn sie zwingend benoetigt werden (und das kann bei manchen
Parametern auch zu einem Zeitpunkt sein, wo Dateien, deren Name vorher auf
der Kommandozeile angegeben waren, bereits vollstaendig verarbeitet wurden).
In dieser Allgemeinheit ist der Satz also nicht zwingend richtig.
Die einzige Auswertung, die *grundsaetzlich* *immer* vor der Verarbeitung
der Daten (also "erst mal") statt findet, macht die shell.
Stefan Reuther
> Erich Fruehstueck <ef....@aon.at> wrote:
>>Am Sun, 24 Oct 2010 01:09:40 +0000 schrieb Juergen Ilse:
>>>Es ist der groesste Teil der "Kommandozeilenauswertung".
>>
>>Niemand bestreitet, das die Shell ihre Kommandozeilen aufbereitet. Das
>>ändert aber nichts daran, dass die Aussage
>>
>>"Jeder Befehl wertet erst mal die Argumente aus."
>>
>>richtig ist.
>
> Woher weisst du von "jedem Befehl" dass er "erst mal die Argumente aus-
> wertet"?
Die einzigen Befehle, die das nicht tun, sind 'true' und 'false'. Und
selbst da werten die GNU-Versionen '--version' und '--help' aus.
> Wenn die Kommandozeilenparameter (z.B. Dateinsmen) sequentiell
> abgearbeitet werden, werden sie evt. von jenem Befehl jeweils erst dann
> ausgewertet, wenn sie zwingend benoetigt werden
Ah, jetzt streiten wir uns nicht mehr über die Definition von
'auswerten' sondern von 'erstmal' *facepalm*
> Die einzige Auswertung, die *grundsaetzlich* *immer* vor der Verarbeitung
> der Daten (also "erst mal") statt findet, macht die shell.
So?
execl("/bin/cat", "cat", "/etc/profile", (char*) 0);
Stefan
Erich Fruehstueck
> Hallo,
>
> Erich Fruehstueck <ef....@aon.at> wrote:
>> Am Sun, 24 Oct 2010 01:09:40 +0000 schrieb Juergen Ilse:
>>> Es ist der groesste Teil der "Kommandozeilenauswertung".
>> Niemand bestreitet, das die Shell ihre Kommandozeilen aufbereitet. Das
>> Àndert aber nichts daran, dass die Aussage
>>
>> "Jeder Befehl wertet erst mal die Argumente aus."
>>
>> richtig ist.
>
> Woher weisst du von "jedem Befehl" dass er "erst mal die Argumente aus-
> wertet"? Wenn die Kommandozeilenparameter (z.B. Dateinsmen) sequentiell
> abgearbeitet werden, werden sie evt. von jenem Befehl jeweils erst dann
> ausgewertet, wenn sie zwingend benoetigt werden (und das kann bei
> manchen Parametern auch zu einem Zeitpunkt sein, wo Dateien, deren Name
> vorher auf der Kommandozeile angegeben waren, bereits vollstaendig
> verarbeitet wurden). In dieser Allgemeinheit ist der Satz also nicht
> zwingend richtig.
Du hast ja beim Zitieren wohlweislich die Passage "Ausnahmen sind
Befehle, die keine Argumente berücksichtigen oder die Argumente nur in
einer sehr trivialen Form nutzen" weggelassen. Was glaubst Du, warum das
wohl dort stand?
Die "Null"-Auswertung*) ist auch eine Auswertung. Mathematiker haben eine
Vorliebe für Verallgemeinerungen ;)
*) Null-Auswertung := Sonderform einer Auswertung, bei der nichts zu tun
ist (z.B. Argumente ignorieren).
> Die einzige Auswertung, die *grundsaetzlich* *immer* vor der
> Verarbeitung der Daten (also "erst mal") statt findet, macht die shell.
Wo bitte werden bei Ausführung nachstehenden C-Programms
die Argumente des Befehls "ls" von einer Shell ausgewertet?
#include <unistd.h>
int main (int argc, char **argv)
{
execl("/bin/ls", "ls", "-l", NULL);
Egon Schmid
>> Der Befehl selbst:
>> ==================
>> Jeder Befehl wertet erst mal die Argumente aus.
>
> Falsch. Die shell wertet die Parameter aus und startet das Programm mit
> den bereits ausgewerteten Parametern. Das ist ein erheblicher Unterschied
> zu dem, was du dort oben geschrieben hast. Da fast jedes unixoide System
> eine unix-shell mitbringt, ist es nicht weiter verwunderlich, dass solche
> Systeme in dem Punkt uebereinstimmen (wenn auch nicht ganz so wie du es
> dort oben geschrieben hast).
Jedes Programm bekommt beim Start ein String-Array übergeben, dass
müsste jeder Programmier-Anfänger. Ob in Java, Perl, C/C++, etc...
Und jedes Programm muss erst mal prüfen, ob diese syntaktisch korrekt
sind und es damit was anfangen kann.
Sind die Parameter falsch, bricht das Programm ab und gibt noch _meist_
eine Zeile wie
Usage: [OPTIONS] file1 file2 ...
aus.
Gruß
Egon Schmid
Felix Palmen
> Woher weisst du von "jedem Befehl" dass er "erst mal die Argumente aus-
> wertet"?
Bei allem nötigen Respekt (hint: keinem), Sie sind ein Vollidiot.
*plonk*
Rainer Weikusat
> * Egon Schmid <egon....@dischingen.de>:
>> Es gibt gewisse Dinge, die haben (fast) alle Unix-Pakete/Programme
>> gemeinsam.
>>
>> Bei der Installation:
>> =====================
>> Mit "sh configure [OPTIONS]" oder "./configure [OPTIONS]" wird das
>> System analysiert und ein Makefile generiert.
>>
>> Danach kann man mittels "make install" die Software installieren.
>
> GNU Autotools. Die sind ein bisschen problematisch zu erlernen, aber
> wenn man sich erstmal zurechtfindet (und so halbwegs die nicht ganz
> allem wenn es um maximale portabilit�t des Build-Systems geht.
In der Tat. Das build-system wird so 'maximal' portabel sein, dass es
noetigenfalls mit Dynix oder sonst etwas seit zehntausend Jahren totem
zurecht kaeme, aber garantiert eine groesseren Portierungsaufwand nach
sich ziehen, sobald jemand versucht, es auf einem zweiten PC zu
benutzen (Dies ist eine Hyperbel. Insbesondere die Aussage, GNU
autounfall sei frueher sinnvoller gewesen waere, als heute).
Betriebssysteme sind mittlerweile sehr viel einheitlicher, als sie das
kurz nach der Schlacht um Stalingrad (oder war das Konstantinopel?)
waren, und das uebliche Resultat von 'autoconf' ist dass das
build-system aufwendig portiert werden muss, um die Software, die
selber keine Portabilitaetsprobleme verursachen wuerde, uebersetzen zu
koennen.
Nein, ich rechne nicht damit, in Zukunft keine Zeit mehr mit der
schoenen Taetigkeit, riesige Shell-scripte, die vollkommen sinnfreie
Operation durchfuehren, zu verstehen und gezielt aendern zu
muessen. Im Computer-Bereich trennt mich sich nicht bloss deswegen von
einer Technologie, weil sie keinen wie-auch-immer gearteten Nutzen
bringt, aber allbekanntermassen schadet. Da koennte man ja gleich
seine Meinung bloss deswegen aendern, weil sie unsinnig ist ...
Richard W. Könning
>Juergen Ilse wrote:
>> Erich Fruehstueck <ef....@aon.at> wrote:
>>>Am Sun, 24 Oct 2010 01:09:40 +0000 schrieb Juergen Ilse:
>>>>Es ist der groesste Teil der "Kommandozeilenauswertung".
>>>
>>>Niemand bestreitet, das die Shell ihre Kommandozeilen aufbereitet. Das
>>>�ndert aber nichts daran, dass die Aussage
>>>
>>>"Jeder Befehl wertet erst mal die Argumente aus."
>>>
>>>richtig ist.
>>
>> Wenn die Kommandozeilenparameter (z.B. Dateinsmen) sequentiell
>> abgearbeitet werden, werden sie evt. von jenem Befehl jeweils erst dann
>> ausgewertet, wenn sie zwingend benoetigt werden
>
>Ah, jetzt streiten wir uns nicht mehr �ber die Definition von
>'auswerten' sondern von 'erstmal' *facepalm*
Es geht eigentlich nicht um die Definition, sondern um die Position
von "erstmal". J�rgens Punkt w�rde eher zutreffen, wenn der Satz
gelautet h�tte: "Erstmal wertet jeder Befehl die Argumente aus", da
man dann sagen k�nnte: erstmal kommt die Shell dran. Da aber der Satz
mit "Jeder Befehl" beginnt, sollte eigentlich klar sein, da� sich der
Fokus beim Nachfolgenden auf das eingeschr�nkt hat, was der Befehl
macht.
Ciao,
Richard
--
Dr. Richard K�nning He�stra�e 63
Tel.: 089/5232488 80798 M�nchen
Felix Palmen
> Nein, ich rechne nicht damit, in Zukunft keine Zeit mehr mit der
> schoenen Taetigkeit, riesige Shell-scripte, die vollkommen sinnfreie
> Operation durchfuehren, zu verstehen und gezielt aendern zu
> muessen.
Wenn du DAS allen Ernstes im Kontext "autotools" schreibst, machst du
damit was grundlegendes falsch. Wobei der Satz unvollständig war, daher
lege ich mal das für mich naheliegendste Verständnis zugrunde.
M4 sowie ein ansonsten komplett scriptbasierter Ansatz ist nicht
jedermanns Sache, daher hatte ich explizit auf Alternativen hingewiesen.
Dennoch habe ich nie die Notwendigkeit einer Alternative /für mich/
gesehen. Die autotools machen ihren Job wunderbar, aber natürlich kann
man sich mit so ziemlich jedem Werkzeug auch prima in den Fuß schießen.
Ich vertraue jedenfalls lieber auf lange erprobtes. Und
Portabilitätsprobleme einfach "wegzudefinieren" ist eindeutig
Wunschdenken.
Rainer Weikusat
> * Rainer Weikusat <rwei...@mssgmbh.com>:
>> Nein, ich rechne nicht damit, in Zukunft keine Zeit mehr mit der
>> schoenen Taetigkeit, riesige Shell-scripte, die vollkommen sinnfreie
>> Operation durchfuehren, zu verstehen und gezielt aendern zu
>> muessen.
>
> Wenn du DAS allen Ernstes im Kontext "autotools" schreibst, machst du
> damit was grundlegendes falsch.
In der Tat. Zum Beispiel habe ich ein paar Jahre lang existierende
auto*-Buildsysteme so lange treten muessen, bis sie mit einem
Crosscompiler benutzbar waren, und in zT nichttrivialen Umfang Features
zu solchen hinzufuegen muessen.
[...]
> M4 sowie ein ansonsten komplett scriptbasierter Ansatz ist nicht
> jedermanns Sache, daher hatte ich explizit auf Alternativen hingewiesen.
> Dennoch habe ich nie die Notwendigkeit einer Alternative /f�r mich/
> gesehen. Die autotools machen ihren Job wunderbar, aber nat�rlich kann
> man sich mit so ziemlich jedem Werkzeug auch prima in den Fu�
> schie�en.
Das schoene an autodurchfall ist ja gerade , dass man damit immer nur
anderen in die Fuesse schiesst. Naemlich Leuten, die die Software
tatsaechlich portieren muessten, wenn autoblurdybloop nicht
typischerweise der einzige unportable Teil waere.
> Ich vertraue jedenfalls lieber auf lange erprobtes. Und
> Portabilit�tsprobleme einfach "wegzudefinieren" ist eindeutig
> Wunschdenken.
Portabilitaetsprobleme loesen sich nicht dadurch von alleine, dass man
irgendein Framework irgendwie benutzt.
Felix Palmen
verunglimpft, muss ich nicht über dessen Sinn und Nützlichkeit
diskutieren. Sagen wir einfach, ich bin anderer Meinung -- EOD.
Juergen Ilse
Rainer Weikusat <rwei...@mssgmbh.com> wrote:
> fe...@palmen-it.de (Felix Palmen) writes:
>> Wenn du DAS allen Ernstes im Kontext "autotools" schreibst, machst du
>> damit was grundlegendes falsch.
> In der Tat. Zum Beispiel habe ich ein paar Jahre lang existierende
> auto*-Buildsysteme so lange treten muessen, bis sie mit einem
> Crosscompiler benutzbar waren, und in zT nichttrivialen Umfang Features
> zu solchen hinzufuegen muessen.
Vor etlichen Jahren versuchte ich einmal Gnu-tar unter AIX2.2 zu compi-
lieren. Da hat man schon permanent den Eindruck, gegen den auto* Schlamm
ankaempfen zu muessen, aber es war zumindest moeglich. Bei der bash (wo
sich make und dieses auto* generierte Zeugs gegenseitig aufriefen und
somit im Laufe des build-Prozesses manuelle Aenderungen und Anpassungen
der Sources wieder rueckgaengig gemacht wurden, weil manuell angepasste
Dateien wieder mit dem unpassenden autogenerierten Zeug ueberschrieben
wurden) habe ich dann nach einigen verzweifelten Stunden aufgegeben ...
AIX3.x wurde durch den auto* Kram beruecksichtigt, so dass man dort das
Problem nicht hatte. Wer einmal mit solchen Problemen zu kaempfen hatte,
hat dabei mit Sicherheit gelernt, diese Automatismen abgrundtief zu
hassen und sich ausfuehrlich kommenttierte Makefiles zurueckzuwuenschen,
die man mit einem Editor an das eigene System anpassen muss ...
Rainer Weikusat
> Ich glaube mit jemand, der ein Tool bereits bei jeder Nennung namentlich
> diskutieren. Sagen wir einfach, ich bin anderer Meinung -- EOD.
Da ich etwas mehr geschrieben hatte, als bloss eine weitere
autoconf-Verbalhornung (Die zweite geht uebrigens auf Mark Crispin
zurueck, http://www.washington.edu/imap/IMAP-FAQs/index.html#6.1),
koennten 'wir' 'einfach mal sagen', dass Du eine zwar vorgefasste
Ansicht hast (die dem Eigenlob in dem von Dir angefuehrten
autoconf-Buch, dass ich uebrigens seit Jahren besitze, verdaechtich
aehnlich sieht), aber wohl keine Argumente dafuer.
Um das nochmal ausdruecklich zu schreiben: Man *kann* autoconf
et. al. auch benutzen, um portable build-Systeme zu erstellen,
allerdings kann man das auch sehr gut ohne. Ein build-System wird
aber nicht dadurch portabel, das autoconf dazu benutzt wurde,
und ein solches gegebenenfalls soweit anzupassen, dass es tatsaechlich
mit auch nur unwesentlich anderen Zielplattformen funktioniert (dh
Linux/ARM mit Cross-Compiler anstatt von Linux/x86), ist eine
Taetigkeit, die ich aufgrund schmerzlicher Erfahrungen meinem aergsten
Feind nicht an den Hals wuenschen wuerde. Viele Teile von autoconf
sind auch mittlerweile technisch obsolet, zB besteht im allgemeinen
keine Notwendigkeit mehr, um seltsame vendor-make-Versionen auf
prae-ANSI-C Exoten-Unixen herumzuwuergen, oder jedenfalls nicht mehr
in dem Umfang, in dem sich groessere Kniebeugen dafuer rechtfertigen
liessen. Richtig unerfreulich wird es dann, wenn man auf einem Rechner
auch noch mehrere Versionen aller autotools installiert haben muss,
weil bestimmte build-Systeme, die man benutzten muss [ausser man
moechte sie in toto ersetzen], nur mit bestimmten und
theoretisch laengst veralteten auto*-Versionen funktionieren ...
Felix Palmen
> Da ich etwas mehr geschrieben hatte, als bloss eine weitere
> autoconf-Verbalhornung (Die zweite geht uebrigens auf Mark Crispin
> zurueck, http://www.washington.edu/imap/IMAP-FAQs/index.html#6.1),
> koennten 'wir' 'einfach mal sagen', dass Du eine zwar vorgefasste
> Ansicht hast (die dem Eigenlob in dem von Dir angefuehrten
> autoconf-Buch, dass ich uebrigens seit Jahren besitze, verdaechtich
> aehnlich sieht), aber wohl keine Argumente dafuer.
Wenn ich keine Lust habe, auf stumpfes Bashing einzugehen, habe ich also
keine Argumente. So kann man sich das natürlich auch zurechtdrehen.
> Um das nochmal ausdruecklich zu schreiben: Man *kann* autoconf
> et. al. auch benutzen, um portable build-Systeme zu erstellen,
> allerdings kann man das auch sehr gut ohne. Ein build-System wird
> aber nicht dadurch portabel, das autoconf dazu benutzt wurde,
> und ein solches gegebenenfalls soweit anzupassen, dass es tatsaechlich
> mit auch nur unwesentlich anderen Zielplattformen funktioniert (dh
> Linux/ARM mit Cross-Compiler anstatt von Linux/x86), ist eine
> Taetigkeit, die ich aufgrund schmerzlicher Erfahrungen meinem aergsten
> Feind nicht an den Hals wuenschen wuerde.
Da wäre doch mal die naheliegendste Frage, auf welche
autotools-Versionen sich diese Erfahrung wohl bezieht? Erfahrungen mit
dieser konkreten Plattform habe ich nicht, Erfahrungen mit autotools und
cross-compiling allerdings schon, und das ohne nennenswerte Probleme.
> Viele Teile von autoconf
> sind auch mittlerweile technisch obsolet, zB besteht im allgemeinen
> keine Notwendigkeit mehr, um seltsame vendor-make-Versionen auf
> prae-ANSI-C Exoten-Unixen herumzuwuergen, oder jedenfalls nicht mehr
> in dem Umfang, in dem sich groessere Kniebeugen dafuer rechtfertigen
> liessen.
Das mag sein. Als Nutzer bekommt man davon allerdings in aller Regel
nichts mit.
> Richtig unerfreulich wird es dann, wenn man auf einem Rechner
> auch noch mehrere Versionen aller autotools installiert haben muss,
> weil bestimmte build-Systeme, die man benutzten muss [ausser man
> moechte sie in toto ersetzen], nur mit bestimmten und
> theoretisch laengst veralteten auto*-Versionen funktionieren ...
Das passiert bei nicht vernünftig gepflegter Software. Würde ich jetzt
nicht dem Buildsystem anlasten wollen. Dinge, die veraltete Software
voraussetzen, können häufig nerven oder gar an den Rand des Wahnsinns
treiben. Das einzige, was die autotools hier "verbessern" könnten, wäre
die grundsätzliche Beibehaltung von Rückwärtskompatibilität. Ich denke
da gibt es wichtigere Gründe, genau das nicht zu tun.
Grüße,
Felix
Rainer Weikusat
> * Rainer Weikusat <rwei...@mssgmbh.com>:
>> Da ich etwas mehr geschrieben hatte, als bloss eine weitere
>> autoconf-Verbalhornung (Die zweite geht uebrigens auf Mark Crispin
>> zurueck, http://www.washington.edu/imap/IMAP-FAQs/index.html#6.1),
>> koennten 'wir' 'einfach mal sagen', dass Du eine zwar vorgefasste
>> Ansicht hast (die dem Eigenlob in dem von Dir angefuehrten
>> autoconf-Buch, dass ich uebrigens seit Jahren besitze, verdaechtich
>> aehnlich sieht), aber wohl keine Argumente dafuer.
>
> Wenn ich keine Lust habe, auf stumpfes Bashing einzugehen, habe ich also
Ich habe jedenfalls keine Lust, mich mit Leuten herumzuaergern, die in
dem oa Umfang inhaltliche Verdrehungen als Aufhaengepunkt fuer von
ihnen geschriebene Text zu benutzen versuchen.
Wie ein Herr Tucholsky mal sehr schoen geschrieben hat: Die Basis
jeder gesunden Ordnung ist ein grosser Papierkorb.
Egon Schmid
> ... dass müsste jeder Programmier-Anfänger. ...
Ich hab mich da verschrieben, sollte heissen "das weiss jeder
Programmieranfänger".
Gruß
Egon Schmid