[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ein neues buildsystem --> autotools endlich abloesen



On 05.03.06 14:24:38, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > > 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.

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.

> 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)

> > > 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,

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).

> 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. 

> > 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.

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

> > 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).

Gut das dein Arbeitgeber dir die Zeit dafuer gibt, das ist aber nicht
bei allen Leuten so. 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.
Wenn sie Alternativen finden ist das gut, wenn nicht entscheiden sie
sich fuer den leichtesten Weg, der evtl. auch nur ein Workaround ist.

> > > 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 ?

s.o. OpenSSL. Oder irre ich mich da? Was anderes faellt mir so auf
Anhieb nicht ein...

> > > 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 ...

fam == file alteration monitor

Leider total buggy und nicht mehr gepflegt.

> > 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.

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).

> > > > 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 ...

> 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). Ok, jetzt kann man denen sagen: "Ihr koennt mich
mal, CVS ist nur fuer Freaks". Damit vergraulst du die Leute nur und die
wettern dann immer und ueberall gegen das jeweilige Programm, evtl.
sogar gegen das OS... Nicht unbedingt das Ziel der Projekte...

> 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.

> > > 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 ?

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. 

> Trivial.

Nicht zwingend, zur Vermeidung von Verwirrungen musst du die
Versionsnummer ueberall angleichen. Das kann einige Dateien betreffen...
Und das muss irgendwer machen.

> > > > 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. 

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.

> > > 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.

In deiner Welt moechte ich leben. Aber s.o.

> <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 ...

Darauf kann ich leider nicht antworten, weil du wiedermal zuviel
weggesnippt hast.

> > 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.

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... 

> Da darf man sich gern die nötige Zeit für die Qualität nehmen.

Auch bei OSS gibts einen gewissen Zeitdruck. Davon abgesehen kann man
auch mit OSS Geld machen.

> > > 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.

GC? Bei C++? Der war gut. Da musste schon selbst GCen. Und das machen
die recht ordentlich (stichwort RefCounting und Implicit Sharing) IMHO.
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.

> > 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...

> > > > 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)

Im Moment keine Zeit und da ich sowieso lieber Python schreibe das
bereits ein recht ordentliches Build-System hat... ;-) 

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 :-)

> > 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.

Ich definiere das Abfragen der DB und entsprechende Auswertung des
Ergebnisses immernoch als Test. Aber das ist ja erstmal egal.

> > 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

Ob das mit pkg-config und entsprechenden VARIABLEN funktioniert weiss
ich nicht...

Andreas

-- 
You have the body of a 19 year old.  Please return it before it gets wrinkled.



Reply to: