Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
<snip>
> > Ja und ? Wo ist jetzt das Problem ?
> > Dafür gibts conditionals, mit dem sich einzelne optionale Features
> > modellieren lassen.
>
> 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.
<snip>
> 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.
<snip>
> 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
<snip>
> 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.
Solchen Pfusch muß man vermeiden und nicht noch unterstützen.
Wir sind hier ja nicht im Bundestag ...
<snip>
> > 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.
<snip>
> > 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.
Wenn mein Paket eine Library ab Version X.Y.Z benötigt, dann schreib
ich genau das in die jeweilige Abhängigkeit.
<snip>
> > > 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 ?
<snip>
> > 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.
<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.
Wenn das bei einem Paket nicht so gemacht wird, dann muß es
repariert werden, bevor man es seriös verwenden kann.
<snip>
> 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 ?!
<snip>
> > 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.
<snip>
> Sicherlich einiges kann "geshared" werden (Groesse eines int,
> Architektur, Byte-Alignment usw.) aber vieles eben auch nicht.
Das dürfte etwa 95% ausmachen ...
<snip>
> 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).
<snip>
> > 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.
Wenn ich zusammenrechne, wie viel Lebenszeit ich schon für das
Flicken von kaputten autoconf-Gerätz verbrannt habe, dann hätt
ich eigentlich schon generell die Makefiles immer von Hand schreiben
können ...
<snip>
> > Die wesentlichen Strukturen stehen. ca. 200kb source.
> > Wenn im fertigen System vielleicht 1MB rauskommen, dann ist das
> > immernoch im grünen Bereich. Ansonsten ist "schmaler Code"
> > mehr eine Frage des sauberen Designs, statt nur der reinen Quantität.
>
> Korrekt und des richtigen "Frameworks" dass einem die "schmutzige"
> Arbeit abnimmt ;-)
Das "Framework" ist eine kleine, selbstgeschriebene Library von
nochmal 100kb ...
<snip>
> > 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.
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: