Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> Ein Teil davon duerfte auf der miserablen Arbeit der Paketmaintainer
> diverser Mainstream-Distri's beruhen, denn schliesslich wollen die
> Projektentwickler dass man auch auf diesen Distri's das Programm
> kompilieren kann.
Ich denke, beide Parteien tragen Ihren Teil dazu bei.
Aber gerade die Distro-Maintainer sollten da etwas konsequenter
und radikaler in ihren QS-Anforderungen sein.
Beispielsweise gelten bei mir u.A. folgende Anforderungen:
+ Crosscompile in SYSROOT-Umgebung, wo nur absolut die Dependencies
für die gewählte Configuration installiert sind.
-> keinerlei Imports oder andere Abhängigkeiten vom Build-Host.
(insbesondere auch Hardware-Eigenschaften)
-> möglichst keine eigenen Build-Tools im Paket, oder wenn garnich
vermeidbar, dann mit HOST- statt TARGET-toolchain bauen.
+ Vollautomatischer, nicht-interaktiver build.
Config-Parameter werden per cmdline in der passenden Stage übergeben
(zB. Env für gmake, oder Parameter an ./configure, ...)
+ Libraries -> 100% abwärtskompatibel (zumindest auf Quell-Ebene)
> > Du darfst ja gern mal ein paar Positiv-Beispiele nennen.
>
> AFAIK nutzen Gnome-Apps mittlerweile pkg-config um so die Flags/Libs
> usw. "auszuspionieren". Ebenso andere Programme, z.B. die libxml2 (die
> zwar als Gnome-XML-Lib begonnen hat, mittlerweile aber ein
> eigenstaendiges Projekt ist)
Viele Programme nutzen pkg-config, aber das ist eher eine Datenbank.
<snip>
> > Wenn sich in einer Library von einer Version zur nächsten die
> > Interfaces inkompatibel werden, dann ist das ein Designfehler,
>
> Das kommt auf den Versionssprung an... Von 3.4.X auf 4.X.X darf sowas
> sein (um mal beim KDE-Beispiel zu bleiben, Zahlen sind aber beliebig
> austauschbar).
Nein, auch dann nicht. Man muß ein neues Paket / eine neue Library
bauen, also zB. libfoo1, libfoo2, ... diese Libs müssen natürlich
auch problemlos koexistieren können.
<snip>
> > unabhängig vom individuellen Gefühl der jeweiligen Autoren.
> > Solche Libs (-Versionen) sollte man einfach nicht benutzen, sondern
> > ggf. reparieren.
>
> In der Praxis gibts leider Faelle wo sich die Autoren nicht sonderlich
> darum kuemmern ihre ABI kompatibel zu halten und man leider keine
> vernuenftigen Alternativen hat.
Dann muß man eben mal in den sauren Apfel beißen und sich selbst
der Sache annehmen, notfalls eine neue Branche aufmachen.
Übrigends kann ich mit ABI-Inkompatiblitäten zwischen major-Releases
grade so noch leben (evtl. sollte man aber eine ABI-Revision mitpflegen),
aber zumindest auf source-Ebene *muß* es passen - sonst ist das für
mich Schlamperei.
<snip>
> > Ja, manche Leute produzieren gerne Dreck. Aber man sollte nicht
> > wertvolle Lebenszeit damit verschwenden, um jedesmal die Fehler
> > anderer herumzuschiffen, sondern notfalls diese korrigieren.
>
> Kommt halt drauf an ob das umschiffen einfacher/schneller ist als
> das korrigieren. Fuer letzteres muss man die lib naemlich u.U.
> recht genau kennen
Umschiffen hilft nur kurzfristig, aber langfristig handelst Du Dir
damit nur mehr Ärger ein - ein sauberes QM wird damit nämlich
drastisch erschwert.
<snip>
> > 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).
>
> Gut das dein Arbeitgeber dir die Zeit dafuer gibt, das ist aber nicht
> bei allen Leuten so.
Ich bin selbstständig und investiere so viel Zeit, wie ich für
richtig halte. Beispielsweise pflege ich ein dutzend verschiedenste,
individuell konfektionierte Systeme. Meine harte Strategie hilft
mir dabei, den Aufwand in Grenzen zu halten und die Übersicht
zu bewahren.
> Gerade bei OSS ist es auch so, dass die Entwickler nicht unbedingt Lust
> haben kaputten Code von anderen zu reparieren sondern sie moechten halt
> lieber ihre eigenen Dinge weiterentwickeln.
Durchaus verständlich, aber auf Dauer kontraproduktiv.
Ich habe selbst meine Erfahrungen damit machen müssen, wie schwierig
es ist, kleine aber wichtige Fixes in die official branches zu kriegen
(zB. DESTDIR-fix für expat)
Deshalb hab ich mir angewöhnt, meine eigenen Fixes zu pflegen.
<snip>
> Wenn sie Alternativen finden ist das gut, wenn nicht entscheiden sie
> sich fuer den leichtesten Weg, der evtl. auch nur ein Workaround ist.
Sehr kurzsichtig und unkooperativ. Das rächt sich später.
<snip>
> s.o. OpenSSL. Oder irre ich mich da? Was anderes faellt mir so auf
> Anhieb nicht ein...
Aber man kann openssl reparieren.
BTW: wenn hier etwas Interesse besteht, können wir gern ein
Paket- u. Distro-übergreifendes QM-Projekt gründen. Das sollte
allen Distros und auch den Selbstcompilierern zugute kommen.
Ich hab da schon ein paar Sachen in der Richtung getan.
<snip>
> > Wenn die Namen mir jetzt noch was sagen würden ...
>
> fam == file alteration monitor
>
> Leider total buggy und nicht mehr gepflegt.
Wenn Du es benutzt, warum pflegst Du es nicht ?
<snip>
> > 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.
>
> Zumindestens viele, ja. libxml2 wird erst im naechsten Release auf
> pkg-config umgestellt (CVS ist schon), nutzt im Moment aber eine relativ
> kompatible "Eigenentwicklung" xslt-config (mit denselben Parametern).
Wie bereits beschrieben: Solch essentielle Fixes sollten sofort
in ein Bugfix-Release einfließen. Wenn es das offizielle Team
nicht tun will, dann muß man es eben selbst machen.
Interesse besagtem QM-Projekt ?
<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.
>
> Dann duerften bei grossen Projekten interessante Versionsnummern
> rauskommen. 3.9.34656 ...
Nein. Die CVS-Version ist schon die nächste Release-Version, oder
ein Zwischenschritt. Einzelne Zwischenschritte braucht man nicht
extra erfassen - Anwendungen sollen sowie nur fertige Releases nehmen.
<snip>
> > 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.
>
> Siehe auch Mail von Frank, es gibt genug Leute da draussen die
> "interessiert" das nicht, die wollen "einfach mal die neueste Version"
> (warum auch immer).
Pech für sie. Ich nehme nicht auf jeden Stumpfsinn Rücksicht.
<snip>
> Ok, jetzt kann man denen sagen: "Ihr koennt mich mal, CVS ist nur
> fuer Freaks".
CVS ist für Entwickler, nicht Anwender. (Jemand der in seine
Software eine gewisse Lib einbaut, ist auch Anwender dieser)
Wenn ein Paket ein anderes vom CVS braucht, dann beatrachte ich
diese Version als defekt, und ich nehm es nicht.
<snip>
> > Wer für ein Paket eine CVS/SVN-Version eines anderen verlangt,
> > der macht grundlegend etwas falsch.
>
> Fuer releaste Programme: Ja. Fuer in Entwicklung befindliche Programme,
> von denen Snapshots bereitgestellt werden, oder die aus einem SCM
> gezogen werden ist das IMHO durchaus erlaubt.
Nein, auch da nicht.
Wie kann ich mich als Entwickler auf bestimmte Interfaces oder
Features einer Lib velassen, die noch garnicht fest stehen ?
Was im CVS abläuft, steht noch nicht fest (per Def.)
Evtl. sollte man bei gewissen Libs über kürzere Release-Zeiträume
nachdenken und erstmal eine Sache zuende bringen, bevor man eine
andere anfängt. Manchmal sollte man auch kleinere Brötchen backen
und Libs aufsplitten.
<snip>
> > 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 ?
>
> Es geht nicht darum dem in Entwicklung befindlichen Code 1
> Versionsnummer zu geben. Sondern bei jeder Aenderung, deswegen kaemen
> bei grossen Projekten sicher schnell Nummern in den 100ern oder 1000ern
> zusammen.
Siehe oben. Nicht jede kleine Fitzel-Änderung soll eine neue Version
bekommen, sondern nur eine "dummy-Version" für den aktuellen
Entwicklungsstand.
Nicht-released'ter CVS-Code gehört nicht in die Hände des Anwenders.
<snip>
> > Die CVS/SVN-Versionen sind für die Entwicklung des betreffenden
> > Paketes da, nicht zu dessen Nutzung durch andere.
>
> Nicht wenn ich zeitnah ein neues Release meiner Applikation/Library
> veroeffentlichen will. Oder wenn ich bestimmte Dinge fuer eine
> zukuenftige Version, die nur im CVS verfuegbar sind, ausprobieren will
> dabei aber bestimmte noch vorhandene Fehler umschiffen muss.
Nochmal zur Klarstellung:
a) Fehler in importierten Libs umschiffst Du nicht. Du korrigierst
den Fehler und importierst die korrigierte Version.
Wenn nötig eigene Branche aufmachen.
b) von experimentellen CVS-Features läßt Du als Anwendungsentwickler
die Finger weg.
Mein Buildsystem ist auf saubere, robuste, konsistente Software-
Entwicklung konzipiert, nicht für wildes Gefummel. Wenn Du aber
fummeln möchtest, dann werde ich Dir nicht behilflich sein.
<snip>
> > 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.
>
> In deiner Welt moechte ich leben. Aber s.o.
Kannst Du. Du mußt nur wollen.
<snip>
> > 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.
>
> Auch bei OSS gibts sowas, klaro ist da eher "Es ist fertig wenn es
> fertig ist" das Motto. Dennoch denke ich werden vielfach Libraries und
> Anwendungen mit CVS-Versionen von Bibliotheken entwickelt um moeglichst
> frueh die neuen Features testen zu koennen...
Das ist aber wieder Pfusch. Nicht die Anwendungsentwickelr sind zum
Testen einer Lib da, sondern das QM-Team der Lib. Erst wenn die neue
Version fertig ist, kann sie der Rest der Welt genutzt werden.
Jaja, Projektmanagement in OSS ist nicht ganz trivial, weil es da
ja keine Kommandostrukturen gibt ;-)
<snip>
> > Da darf man sich gern die nötige Zeit für die Qualität nehmen.
>
> Auch bei OSS gibts einen gewissen Zeitdruck.
Diesem sollte man sich aber nicht ungehemmt aussetzen.
> Davon abgesehen kann man auch mit OSS Geld machen.
Klar, tu ich ja auch. Aber trotzdem halte ich meinen Kurs,
bzw. auch gerade deshalb.
<snip>
> > 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.
>
> GC? Bei C++? Der war gut. Da musste schon selbst GCen.
boehm-gc ?
> Und das machen die recht ordentlich (stichwort RefCounting und
> Implicit Sharing) IMHO.
Ungenügender Ansatz. Funktioniert nicht bei Ringstrukturen.
> Was mich auch wundert: Qt ist relativ erfolgreich, sowohl in der
> kommerziellen als auch der nicht-kommerziellen Welt. Und das wohl
> auch nicht nur im GUI-Sektor.
Wundert mich eigentlich nicht mehr. Mein Menschenbild ist mit den
Jahren hinreichend desillusioniert worden.
Eines der wesentlichen Konzeptionsfehler von Qt ist, daß es zu
viel auf einmal will.
BTW: kann man mittlerweile auch eine Qt-Anwendung ohne grafisches
Display (Xserver, etc) starten ? Mein letzter Versuch bei qt3
schlug da fehl. Deshalb mußte ich bei einer Anwendung, die ich
eigentlich nur GUI-frei machen wollte, sämtliche Qt-Abhängigkeiten
entfernen. Sowas war ich eigentlich nur aus der Teletubbi-Welt
gewohnt ... aber der Kommerz-Stumpfsinn hat eben schon längst
auch in der OSS-Welt einzug gehalten :(
<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"
>
> Windows ist so erfolgreich weil es massiv gesponsort wird, von ueberall.
> Und weil es fuer die meisten Dinge auch ausreicht. Es besteht oftmals
> einfach kein Bedarf den Aufwand zu treiben da noch ein anderes OS
> aufzuspielen...
Die gleiche Argumentation könnte man auch für GNU/Linux benutzen.
Offentsichtlich ist das nicht der tragende Grund. Man sieht das auch
an der weiten Verbreitung des OSS-Windows-Nachbaus ...
Psychische Defizite der breiten Masse dürften wohl die Hauptursache
darstellen ...
<snip>
> Im Ernst: Ich hab im Mai wieder etwas Luft und werde wirklich mal
> schauen. Vllt. bringt mir dein Build-System ja doch noch vernuenftige SE
> bei :-)
Okay, ich nehm Dich beim Wort ;-)
<snip>
> > Nein, das ist eine Datenbank-Abfrage. Die Datenbank wird auf irgenteine
> > geeignete Weise gepflegt - Details sind dem importierenden Paket
> > aber scheißegal.
>
> Ich definiere das Abfragen der DB und entsprechende Auswertung des
> Ergebnisses immernoch als Test. Aber das ist ja erstmal egal.
Schlecht, weil Du damit zwei grundlegend verschiedene Dinge gleichschaltest
und wir damit grundsätzlich aneinander vorbei reden.
<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 ?
>
> Ehrlich: Da fragste den Falschen. Ein kurzer Blick in --help liefer ein
> paar andere Informationen:
>
> --types Verfügbare KDE-Ressource-Typen
> --path type Suchpfad für diesen Resource-Typ
> --userpath type Benutzerdefinierter Pfad: desktop|autostart|trash|document
> --install type Präfix, in dem Resource-Dateien abgelegt werden
> --exec-prefix Bei der Kompilierung gesetztes "exec_prefix" für die KDE-Bibliotheken
> --libsuffix Bei der Kompilierung gesetztes "library path suffix"
> --localprefix In $HOME verwendetes Präfix, in dem Dateien abgelegt werden
> --version Bei der Kompilierung gesetzte Versionsangabe für die KDE-Bibliotheken
Aha. Es scheint wohl eine kde-spezifische Erweiterung darzustellen.
Ob das wirklich sinnvoll ist, kann ich nicht beurteilen - schließlich
lebe ich ja konsequent Qt- und KDE-frei.
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: