Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> > Selbstverständlich kann er das.
> > Aber er kann nicht einfach irgentwelche "Tests" basteln, die
> > irgentwas im System rumrätseln und daraufhin Conditionals schalten.
>
> Nicht alle Tests sind "rumraetseln".
Wohl aber 90% (bei autootols).
Zu probieren, ob sich diese oder jene Lib einlinken läßt oder
auszuprobieren, mit welchen Compiler/Linker-Parametern sich ein
Stück Code mit einem bestimmten Funktionsaufruf compilieren läßt,
halte ich für ziemlich derbes Gefrummel - und genau so arbeiten
die meisten dieser checks bei autotools.
Du darfst ja gern mal ein paar Positiv-Beispiele nennen.
<snip>
> > Schlecht gewähltes Beispiel. Wenn sowas in einer Library passiert,
> > dann muß man diese erstmal wieder reparieren. Pfuschcode import
> > man nicht, wenn man seriös arbeiten möchte.
>
> ROFL. Nicht immer ist das ein "Fehler" im Sinne der Library-Autoren.
Wenn sich in einer Library von einer Version zur nächsten die
Interfaces inkompatibel werden, dann ist das ein Designfehler,
unabhängig vom individuellen Gefühl der jeweiligen Autoren.
Solche Libs (-Versionen) sollte man einfach nicht benutzen, sondern
ggf. reparieren.
<snip>
> Es gibt nunmal Leute die das alles nicht interessiert, die machen
> halt was sie wollen. Prominentes Beispiel: OpenSSL und da kommt man
> bei bestimmten Applikationen schwer/gar nicht vorbei.
Ja, manche Leute produzieren gerne Dreck. Aber man sollte nicht
wertvolle Lebenszeit damit verschwenden, um jedesmal die Fehler
anderer herumzuschiffen, sondern notfalls diese korrigieren.
Openssl gehört mit zu den Paketen, die ich regelmäßig
zu flicken habe.
<snip>
> Wie oft man mit Pfuschcode arbeiten _muss_ und darum herumwerkeln muss
> habe ich schon live gesehen.
Ich stehe in der Praxis oft genug vor diesem Problem, aber ich weigere
mich, rumzupfuschen, nur weil es andere auch tun, sondern ich repariere
den Pfuschcode (manchmal lohnt es sich auch, alles komplett neu zu
programmieren).
<snip>
> Da gibts die Vorgabe Framework X zu benutzen, weil das ja schon da ist
> und nix kostet, egal welche Fehler da drin sind oder wie wenig sich die
> Entwickler um korrekte Sonames oder aehnliche Dinge kuemmern.
Auch hier gilt: konsequent reparieren und/oder dem Auftraggeber auf
seine Fehlentscheidung hinweisen.
<snip>
> > Zwei Fälle: a) gtk1, b) gtk2.
> > Wir führen hier ein Conditional mit zwei Varianten ein - der erste,
> > "gtk1", enthält die Codeteile für die gtk1-Implementation und
> > einen Import zur libgtk, während beim zweiten, "gtk2" analog dazu
> > zur libgtk2
>
> Ja, aber dein Buildsystem muss "irgendwie" rauskriegen ob gtk1 oder gtk2
> installiert ist.
Es fragt einfach die Paket/Library-DB ab.
pkg-config ist da schon ein recht brauchbarer Ansatz.
<snip>
> Weiterhin: Was ist wenn Version 1.4.1 eine Funktion enthaelt mit einem
> Fehler fuer das aber ein bekannte Workaround existiert. Version 1.4.0
> hat diesen Fehler nicht (sowas passiert auch bei gutem Design).
Dann muß das eben repariert werden, und wir verlangen die reparierte
Version (zb. 1.4.1.1). Workarounds sind Pfusch.
<snip>
> Du willst aber als Applikationsentwickler es erlauben das auch GTK1
> 1.4.1 benutzt werden kann, weil dort ein anderer viel wichtigerer (weil
> sicherheitsrelevanter) Bug geschlossen wurde.
Nein, will ich nicht. Wenn 1.4.1 defekt ist, dann soll es nicht genommen
werden. Notfalls warten bis 1.4.1.1 bzw. diese selbst herstellen.
Wie ich bereits sagte: das Problem an der Wurzel packen !
Jede Library hat strikt definierte Interfaces aufzuweisen, die zuverlässig
funktionieren. Funktioniert das nicht, dann ist die Lib eben defekt.
Als Anwendungsentwickler sollte man sich nicht für das schlechte
Qualitätsmanagement bei einzelnen Libs verantwortlich fühlen
(es sei denn man nimmt sich selbst dessen konsequent an)
<snip>
> > Siehe oben. Dann erstmal die Library reparieren.
>
> Wenn man das kann, was nicht immer geht und bevor du mir jetzt
> erzaehlst das man sich dann ne Alternative sucht: Die gibts nunmal
> nicht immer und ueberall.
Beispiel ?
<snip>
> > Solchen Pfusch muß man vermeiden und nicht noch unterstützen.
>
> Sag das bitte mal den OpenSSL Entwicklern.
Hab ich schon oft genug. Und da die nicht unbedingt von Einsichtigkeit
gesegnet sind, pfege ich meine eigenen Patches. Übrigends für
zahlreiche andere Pakete auch.
<snip>
> > Nur wenn ein Paket wirklich eine *neue* Version benötigt.
> > Nach den ersten paar Releases (wenn erstmal eine hinreichende Menge
> > Pakete portiert ist), wird sich nicht mehr viel ändern. Allenfalls
> > die Target-Profile müssen ab und an mal angepaßt werden.
>
> Glaubst du, wie schnell sich Anforderungen und benutzte Libraries
> aendern sieht man im OSS Umfeld haeufiger. fam z.B. wurde ungefaehr 1.5
> Jahre nachdem ich das erste Mal davon gehoert habe durch gamin abgeloest
> (bzw. ist das noch ein wenig im Gange). Sarge hat 3! Jahre gebraucht um
> stable zu werden.
Wenn die Namen mir jetzt noch was sagen würden ...
<snip>
> > Rumgetestet wird nicht. Man nimmt Infos aus einer Datenbank.
>
> Also sowas wie pkg-config?
Ja sicher !
Pkg-config ist sicher nicht perfekt, aber ein guter, bewährter
Kompromiß, und es wird mittlerweile sehr weitgehend benutzt.
<snip>
> Dann musst du deine Datenbank-Implementierung in _alle_
> Programme/Libs einbauen.
Jedes halbwegs aktuelle und gut gepflegte Library-Paket bringt
.pc-Files mit. Damit gibt es schon einen de-facto-Standard für
die Datenbasis, den man einfach nur nutzen braucht.
Trivial.
<snip>
> Insbesondere bei denen die bereits pkg-config oder sowas benutzen,
> die musst du naemlich erstmal ueberzeugen...
Nein, wozu ?
Ich greife einfach auf die pkg-config-Datenbank zu. Die reicht
ganz gut hin.
<snip>
> > > Es geht nicht um Release-Versionen.
> >
> > Sondern ?
>
> Na um SVN/CVS checkouts.
Die kriegen auch Versionsnummern. Man muß die ja nicht mit jedem
neuen patch erhöhen. Wer CVS/SVN-Versionen verwendet, von dem darf
man erwarten, daß er selbst weiß, wann ein update nötig ist,
auch bei unveränderter Versionsnummer.
Wer für ein Paket eine CVS/SVN-Version eines anderen verlangt,
der macht grundlegend etwas falsch.
<snip>
> > Andere Baustelle. Das Buildsystem kann nicht alle Fehler der
> > Programmierer ausbügeln.
>
> Hae? Wieso Fehler? Was ist falsch daran keine explizite Versionsnummer
> im CVS/SVN zu fuehren? Das ist normale Praxis.
Wieso nimmt man nicht einfach die nächst höhere, die dann für
das nächste Release gedacht ist ? Oder abwechseln:
cvs: 0.0.1.0, release 0.0.1.1, cvs 0.0.1.2, release 0.0.1.3, usw ?
Trivial.
<snip>
> > > Das geschieht wohl nicht haeufig, eher wird die Entwicklung unter einer
> > > Version wie 3.3.99 gefuehrt, was dann in ein 3.4 Release muendet.
> >
> > Und das ist der einzig saubere Weg.
>
> Ja aber ich denke dein Buildsystem erlaubt dem Entwickler der solche
> SVN/CVS-Checkouts nutzt nicht auf bestimmte Features/Fehler zu testen.
Was genau willst Du testen ?
Ob in einer instabilen Entwicklerversion schon ein gewisses Feature
benutzbar ist, oder man noch flicken muß ?!
Die CVS/SVN-Versionen sind für die Entwicklung des betreffenden
Paketes da, nicht zu dessen Nutzung durch andere.
<snip>
> > Wenn das bei einem Paket nicht so gemacht wird, dann muß es
> > repariert werden, bevor man es seriös verwenden kann.
>
> Was die CVS/SVN Version X.X.99 zu benennen?
>
> Oder meinst du Dependecies mit SVN-Revisionsnummern einzufuehren? Hmm,
> das wird auch lustig, SVN-Revisionsnummern sind global fuers
> Repository! Das bedeutet wenn ich auf Revisionsnummer 345 depende kann
> es durchaus sein das meine App auch mit 346 laufen wuerde, weil die
> Aenderungen fuer 346 ein ganz anderes Projekt im gleicehn Repository
> betreffen. Glueckwunsch du hast die Flexibilitaet noch weiter
> eingeschraenkt.
Nein. Siehe oben.
Eine Anwendung soll sich nicht abhängig von unfertigem Code machen.
Man baut ausschließlich auf Releases, nach Möglichkeit auch
nur stable-Releases. Wer das nicht beherzigt, begeht einen schweren
Kardinalfehler - das kann man nicht mehr als seriöse Arbeit bezeichnen.
<snip>
> > Du importierst unfertigen Libs während Du Anwendungen entwickelst ?!
>
> Importieren tue ich gar nix (naja bei PyQt schon), wenn dann include ich
> einen Header und linke gegen eine Library.
Das ist wohl dasselbe. Im Fall von C(++) besteht das Importieren eben
aus zwei Schritten (include und link-against), bei anderen Sprachen,
zB. Oberon oder Java ist das ein Schritt. Aber solche fitzigen Details
haben in der generellen Modellinerung nichts zu suchen.
Def: Import a module = use a library within another one.
<snip>
> Und ja, das tue ich und ich bin mit Sicherheit nicht der einzige.
Dann ist vielleicht mein Buildsystem genau das richtige für Dich,
weil Du dann gezwungen wirst, sauber zu arbeiten ...
<snip>
> Natuerlich nicht gegen die instabilste Version die man kriegen
> kann, aber wenn du eine neue Version deiner Applikation zeitnah
> rausbringen willst (User warten ungern ne Woche oder 2) dann musst
> du das tun.
Okay, die Qualität der Geschwindigkeit opfern. In der kommerzwelt
ist das leider allzu oft die Praxis (manchmal sogar legitim, wenn sich
der Mehraufwand fürs Gepfusche und nachträgliche Reparaturen durch
zeitige Fertigstellung rechnet - bei Inhouse-Anwendungen durchaus
sinnvoll, bei Standardsoftware aber tödlich).
Mein Buildsystem ist aber für saubere und robuste OSS gedacht.
Da darf man sich gern die nötige Zeit für die Qualität nehmen.
<snip>
> Ausserdem moechte man als App-Entwickler ja auch die Zeit haben
> sich auf neue Features "einzuschiessen".
Wenn Du basteln willst, dann mußt Du selbst basteln. Erwarte nicht
von einem Buildsystem, das für absolut robuste und zuverlässige
Pakete konzipiert ist, daß es Dir beim Fummeln hilft.
<snip>
> > KDE ist auch keine Referenz für sauberes Software-Design.
>
> Sag das mal den KDE-Leuten. Ich vermute Gnome ist ebenso ein
> Negativ-Beispiel fuer dich? Und Qt? Apache(2)?
Gnome ist da schon etwas besser.
Qt halte ich für den klassischen Kommerz-Pfusch. Überladene,
überzüchtete eierlegende Wollmilchsau, die nichtmal ein paar
Grundlegende moderne Konzepte wie garbage collection brauchbar
verwendet. Kaum besser als Windoze.
(Vielleicht ist es ja in letzter Zeit besser geworden - ich lebe
nun schon seit längerer Zeit konsequent Qt-frei).
Apache2 ist ein gutes Stück Software, das von meinem Modell
gut profitieren wird, insbesondere was das Modulsystem betrifft.
(in fact: viele Ideen dazu stammen direkt aus meiner Arbeit am httpd2)
<snip>
> Frag mich nur warum davon so viele so erfolgreich sind....
KDE ist bunt. Die Herde will buntes.
Die Frage ist (semi-)equivalent mit "warum ist windows so erfolgreich"
<snip>
> > > Sicherlich einiges kann "geshared" werden (Groesse eines int,
> > > Architektur, Byte-Alignment usw.) aber vieles eben auch nicht.
> >
> > Das dürfte etwa 95% ausmachen ...
>
> Ich glaube nicht, aber gut ich habe keine Zahlen um das zu bekraeftigen
> und sage deswegen dazu nichts weiter.
Vertrau mir einfach mal, bau ein bissl mit und genieße dann die
Früchte Deiner/Unserer Arbeit. IMHO konstruktiver und nützlicher,
als überall nur Bedenken zu suchen (jaja, das Land der Bedenkenträger)
<snip>
> > Siehe oben. Auf Bibliotheken testet man nicht - man importiert sie
> > einfach, und zwar indem man in der entsprechenden Datenbank nachschaut
> > und ggf. nötige Infos rauszieht (zB. pkg-config).
>
> Komm mal von dem Java-Slang weg ;-)
Falls Dir der Begriff "importieren" aufschlägt - der ist schon ein
paar Jahrzehnte älter als Java. Ansonsten siehe Def. oben.
> Wenn ich pkg-config frage ob Bibliothek X installiert ist, dann ist
> genau das ein Test.
Nein, das ist eine Datenbank-Abfrage. Die Datenbank wird auf irgenteine
geeignete Weise gepflegt - Details sind dem importierenden Paket
aber scheißegal.
Ein Test wäre zB. Probieren, ob sich eine bestimmte lib einlinken
läßt, ob ein bestimmte Header-File included werden kann, oder
bestimmte Typen und Funktionen existieren.
Beispiel: manche Standard-Routinen stecken mal direkt in der libc,
mal in einer externen lib (zB. dlfcn). autoconf probiert dann einfach
verschiedene Varianten durch und nimmt die erste beste.
Sauber wäres es, eine Wrapper-Library zu definieren, die man einfach
importieren (pkg-config query oder .la-import) kann. Diese wird dann auf
die einzelnen Plattformen angepaßt und liefert dem Buildsystem die
entsprechenden Toolchain-Optionen, bringt ggf. noch include-Files mit, etc.
(Ahja, eine solche Library muß ja nicht zwingend eigene binary
objects - .a/.so - liefern)
<snip>
> Ja das geschieht bei KDE, allerdings sollte das mit 3.4 langsam obsolet
> werden, da auch KDE damit eine pkg-config-aehnliche DB hat.
hmm, warum nicht gleich pkg-config ? was ist da anders / besser ?
<snip>
> Weiterhin, s.o., musst du erstmal alle moeglichen Apps/Libs zu einer DB
> wie pkg-config konvertieren, denn pkg-config selbst ist AFAIK fast nur
> bei GTK Apps ueblich.
pkg-config ist mittlerweile sehr weit verbreitet und kann bequem als
Standard angesehen werden. Wenn einzelne Pakete das noch nicht bieten,
dann gilt es, das zu reparieren (bei einigen hab ich das schon getan).
> > Weniger für Spaß, sondern als massive Arbeitserleichterung.
>
> Naja, solange du alle Libs/Applikationen build-system-technisch noch
> umschrauben musst, duerfte sich die Arbeitserleichterung in Grenzen
> halten ;-)
Nicht alle, nur manche. Und unterm Strich immernoch günstiger,
als endlos weiter zu pfuschen.
<snip>
> > KDE baut auf Qt. Das sollte schon selbsterklärend sein.
>
> ?? Achso du zaehlst den Aufwand KDE und Qt's Buildsystem umzustellen
> auch noch dazu? Kann ich denn nicht (unter der Vorrausetzung das in der
> DB die libs eingetragen sind) eine beliebige App nehmen und deren
> Buildsystem umstellen?
Ja klar, es reicht wenn die Datenbasis (.pc, .la, ...) korrekt gepflegt
wird. Aber darum gings es mir in dieser Aussage nicht. Siehe weiter oben.
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: