Re: ein neues buildsystem --> autotools endlich abloesen
On 04.03.06 20:45:17, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > Ja, nur wenn ich dich richtig verstanden habe, kann der Entwickler diese
> > conditionals nicht selbst definieren.
>
> 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".
> > siehe anderen Teilthread, ein Funktionsname aendert sich, man will die
>
> 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. 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.
Wie oft man mit Pfuschcode arbeiten _muss_ und darum herumwerkeln muss
habe ich schon live gesehen. 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.
> > alte und die neue Version der Abhaengigkeit unterstuetzten. Das muss
> > man irgendwie testen und wenn diese Tests vom Gremium abgesegnet werden
> > muessen wird das nix werden.
>
> Nein, man testet nicht. Man macht eine Fallunterscheidung, und jeder
> der Fälle hat seine eigenen Abhängigkeiten und Codeteile.
>
> Beispiel: eine GUI-Anwendung
>
> 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.
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).
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.
> > Nicht jede Library/Applikation garantiert dir Binaer-Kompatibilitaet
> > (geschweige denn Source-Kompatibilitaet) innerhalb eines Major-Releases
> > oder auch nur innerhalb eines Minor-Releases...
>
> 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.
> Solchen Pfusch muß man vermeiden und nicht noch unterstützen.
Sag das bitte mal den OpenSSL Entwicklern.
> > > Nicht meine Baustelle. Ich bin kein Debian-Maintainer.
> >
> > Was hat das damit zu tun? Es geht um die User! Die sollten staendig eine
> > neue Version des Buildsystems ziehen nur weil sie nen aktuellen SA
> > brauchen?
>
> 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.
> > > Was haben die Dependencies Deiner Anwendung mit der Version meines
> > > Buildsystems zu tun ? Willst Du etwa einzelne Paketinfos im Buildsystem
> > > hardcoden ?!
> >
> > Du hast erklaert das Tests auf bestimmte Features einer Bibliothek nur
>
> Rumgetestet wird nicht. Man nimmt Infos aus einer Datenbank.
Also sowas wie pkg-config? Dann musst du deine Datenbank-Implementierung
in _alle_ Programme/Libs einbauen. Viel Spass. Insbesondere bei denen
die bereits pkg-config oder sowas benutzen, die musst du naemlich
erstmal ueberzeugen...
> > > > Wie wird das mit CVS/SVN-Versionen von Bibliotheken ohne
> > > > klare Versionsnummer funktionieren?
> > >
> > > Jede Library braucht eine klare Versionsnummer. Man erhöht sie einfach
> > > direkt nach jedem Release.
> >
> > Es geht nicht um Release-Versionen.
>
> Sondern ?
Na um SVN/CVS checkouts.
> > > Ich sehe kein Problem darin, wenn verschiedene (minor-)Revisionen sich
> > > die gleiche Versionsnummer teilen - von jemanden der direkt vom CVS
> > > zieht, darf man beruhigt erwarten, daß (er|sie|es) weiß, was
> > > (er|sie|es) tut ...
> >
> > Ich denke schon das es da Probleme geben wird, sofern die Library nicht
> > grad die Revision (bei SVN) oder das Datum (bei CVS) in die
> > Versionsnummer mit aufnimmt.
>
> 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.
> > 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.
Es gibt ja nunmal keine eindeutige Versionsnummer an der du das
festmachen kannst.
> 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.
> > Innerhalb dieser SVN-Version koennen sich viele Dinge aendern... Klaro
> > wenn ich meine App entwickle kann ich versuchen mich da halbwegs auf
> > dem laufenden zu halten (und commit-logs zu lesen) oder aber ich kann
> > fuer mein Build-System "fix mal" einen Test einbauen ob die Funktion Y
> > immernoch "broken" ist.
>
> 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. Wir reden hier nicht von
Java-Land. Und ja, das tue ich und ich bin mit Sicherheit nicht der
einzige. 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. Ausserdem moechte man als App-Entwickler ja auch die Zeit haben
sich auf neue Features "einzuschiessen".
> > > Ich sehe nur wenig mehr als hundert. Ansonsten sehe ich auch nicht,
> > > was Du checken willst - wir orakeln nicht rum, wir *definieren*.
> >
> > 100? Hmm, ich mag grad kein configure von KDE anwerfen, aber ich moechte
> > behaupten grad bei so Sachen wie kdemultimedia, kdenetwork oder kdepim
> > wo diverse optionale Abhaengigkeiten existieren sind das mehr als 100
> > checks.
>
> 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)?
Frag mich nur warum davon so viele so erfolgreich sind....
> > 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.
> > Und es gibt ziemlich viele Bibliotheken da draussen auf die man
> > testen kann, oder bestimmte Programme...
>
> 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 ;-) Wenn ich pkg-config frage ob
Bibliothek X installiert ist, dann ist genau das ein Test. Ich meinte
damit nicht dass ich versuche ein Programm gegen diese Lib zu linken. Ja
das geschieht bei KDE, allerdings sollte das mit 3.4 langsam obsolet
werden, da auch KDE damit eine pkg-config-aehnliche DB hat.
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.
> > > Das ist *mir* persönlich relativ egal. *Ich* portiere jene Pakete,
> > > die *mich* interessieren, und ich würde freuen, wenn andere ihre
> > > Pakete portieren. Aber wem das nicht paßt, der soll entweder
> > > konkrete Verbessungsvorschläge bringen oder dezent meine Arbeit
> > > ignorieren und seine Klappe halten.
> >
> > Achso, dann machst du das nur so aus Spass fuer dich selbst... Na
> > dann... ;-)
>
> 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 ;-)
Aber vllt. findest du ja noch Mitstreiter...
> > > KDA-Apps würde ich nicht als "klein" bezeichnen, außer vielleicht
> > > im Vergleich zum Openoffice ...
> >
> > Wieso dass nicht? Es geht nicht um so "Monster" wie KOffice,
> > Kontact(inkl. kmail) oder so...
>
> 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?
Andreas
--
You may get an opportunity for advancement today. Watch it!
Reply to: