Re: ein neues buildsystem --> autotools endlich abloesen
On 05.03.06 17:23:45, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > 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.
Genau, damit keiner mehr die Distro benutzt/kauft, da das alle
Distro-Maintainer machen, kauft/benutzt niemand mehr Linux. Ist ja
nicht so schlimm, Alternativen existieren ja.
> + Vollautomatischer, nicht-interaktiver build.
KDE kann man prinzipiell ausm svn vollautomatisch inter-aktiv bauen
lassen. Auch bei Debian's buildd's klappt das sehr gut. Sofern eben
keine Fehler beim Paketieren gemacht wurden, bzw. bei KDE keine Fehler
im aktuellen Code existieren.
> + Libraries -> 100% abwärtskompatibel (zumindest auf Quell-Ebene)
Soll ich jetzt mal ROFL schreiben? Spaetestens bei Major-Versions werden
i.A. die Source-Interfaces geaendert. Nicht wegen schlechtem Design,
sondern weil sich die Anforderungen/Wuensche weiterentwickelt und
veraendert haben. Genau dafuer gibts ja Major-Versions. Innerhalb von
Minor/Bugfix Versionen muss natuerlich Quellkompatibilitaet oder besser
sogar Binaerkompatibilitaet gewaehrleistet sein. Das haben leider nicht
alle Library-Entwickler so verinnerlicht...
100% Abwaehrtskompatibilitaet ist das was Windows bis WinME "versucht"
hat, selbst M$ hat es aufgegeben und mit Win2K/WinXP diese
Kompatibilitaet zugunsten von Wartbarkeit, Stabilitaet usw.
eingeschraenkt. Beim naechsten Windows wirds wohl noch "extremer"
aussehen.
> > > 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.
?? Um sowas anzuzeigen gibts den Soname bei Libraries (im Sinne von
nativen Linux-Libs). Bei Python loest man das ganze wohl mit sog. eggs
oder eben neuen Namen mit der neuen Major-Revision drin.
> > > 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.
Genau, ich schreib mal eben schnell ne SSL library, so in 2 Stunden oder
so? Ich kenn mich zwar mit dem Thema nur rudimentaer aus aber das wird
schon werden...
> Ü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.
So nu muss ich aber wirklich: ROFL.
Wie willst du denn deine Library and neue Anforderungen anpassen? Oder
kennst du alle jemals auftretenden Anforderungen im vorneherein? Achso
du ueberlegst dir einfach nen neuen Namen und startest von vorne.
Major Releases werden genau deswegen gemacht, weil man die ABI und die
API brechen muss um neue Dinge einfliessen zu lassen.
> > 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.
Hmm, ist das nicht auch unguenstig? Ich meine dann muessen die Nutzer
deiner App immer deine expat-Version benutzen. Und der Support fuer die
die das nicht "kapieren" oder sowas wie README's und aehnliches nicht
lesen duerfte einiges an Zeit kosten.
> > > 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 ?
1. Ich bin noch immer Student und hab leider andere Dinge zu tun
2. Ich brauche fam nicht
3. Ich hab von der Materie keine Ahnung (das Teil basiert auf
irgendwelchen notify-Funktionen vom Kernel)
Das reicht mir aus. Ich leiste meinen Teil zu OSS so gut ich kann und
eigentlich beansprucht das jetzt schon mehr Zeit als gut fuer mich
ist...
> > 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)
Da kommen wir wohl nicht ueberein. Naja, lassen wir das Thema.
> Evtl. sollte man bei gewissen Libs über kürzere Release-Zeiträume
> nachdenken
Oh, hast du ne Klon-Maschine um gute Entwickler zu klonen und allen
Projekten so mit unendlich viel Manpower dabei zu helfen? Ich weiss
nicht wie das bei anderen Projekten aussieht und entschuldige bitte dass
ich immer auf das von dir so verhasste KDE zurueckkomme. KDE hat
beschlossen nur noch Bugfix-Releases von KDE3 zu veroeffentlichen damit
moeglichst viel Manpower in KDE4 fliessen kann, dennoch ist der aktuell
anvisierte Release in 1.5-2 Jahren. Anderen OSS Projekten duerfte es
aehnlich gehen.
> und erstmal eine Sache zuende bringen, bevor man eine andere anfängt.
> Manchmal sollte man auch kleinere Brötchen backen und Libs
> aufsplitten.
Aufsplitten loest das Manpower Problem auch nicht.
> > > 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.
Also hast du doch ne Klon-Maschine zumindest fuers QM. Im Moment machen
das zu einem guten Teil die Anwender, die muessen dafuer aber
CVS-Versionen benutzen... Wir drehen uns irgendwie im Kreis. Lassen wir
das.
> Jaja, Projektmanagement in OSS ist nicht ganz trivial, weil es da
> ja keine Kommandostrukturen gibt ;-)
Ich denke in groesseren Projekten gibts schon Kommandostrukturen,
allerdings gibts meistens zu wenig QM-Leute, zu wenig Entwickler, zu
wenig Software-Designer, zu wenig UI-Designer, zu wenig Uebersetzer (hab
ich was vergessen?).
> > > 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 ?
Naja, modern find ich den ja nicht ;-) (Nein ich kenne ihn nicht, nur
anhand der Paper-Daten). Ansonsten ziehe ich mich jetzt lieber aus dem
Thema zurueck, denn mit MM hab ich bisher nicht sooo viel am Hut gehabt
(ausser aufzupassen meine Objekte nicht zu frueh zu deleten). Achja: Ich
habs auch lieber mich nicht drum kuemmern zu muessen, das geb ich schon
zu.
> > Und das machen die recht ordentlich (stichwort RefCounting und
> > Implicit Sharing) IMHO.
>
> Ungenügender Ansatz. Funktioniert nicht bei Ringstrukturen.
Ist klar.
> 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 ?
Ja, mit Qt4.
> Mein letzter Versuch bei qt3
> schlug da fehl.
Korrekt. qt3 braucht eine Gui. AFAIK startete Qt ja wohl auch als
GUI-Framework und hat zumindestens bis Qt3 sein Hauptaugenmerk darauf.
Dinge wie SQL-DB-Anbindung, XML und Netzwerk-Connectivity sollten dem
Anwendungsentwickler einfach nur die Arbeit erleichtern, bzw. dafuer
sorgen dass er nicht noch 4 andere Libs und deren Strukturen verstehen
muss.
> 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 :(
Wenn ich zu Qt3 Zeiten eine Applikation ohne GUI haben haette wollen
haette ich sowieso auf Qt verzichtet, von vorneherein. Soo umwerfend
sind die restlichen Spaesse in der Lib naemlich auch nicht. Da kann man
ruhig ueber ne Alternative nachdenken.
> Psychische Defizite der breiten Masse dürften wohl die Hauptursache
> darstellen ...
ACK. Das merkt man auch immer mal wieder in dieser ML, Lernresistenz und
Faulheit kriegt man halt nicht so leicht weg. Duerfte aber auch nicht
nur durch Software gepraegt werden, auch durch alle andalle anderen
Lebensbereiche.
Andreas
--
You will be married within a year, and divorced within two.
Reply to: