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

Re: ein neues buildsystem --> autotools endlich abloesen



On 04.03.06 14:45:44, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > > Wer dann noch weitere Fälle berücksichtigt werden sollen, dann muß 
> > > das eben mit dem Gremium abgestimmt werden.
> > 
> > Das wird ein no-go sein. IMHO muss ein Buildsystem vom Entwickler
> > erweitert werden koennen wenn sich neuere Anforderungen ergeben. 
> 
> Wieviele Anwendungen hast Du schon programmiert ?

Ne Handvoll wuerd ich sagen... Nichts weltbewegendes...

> > Wenn zum Beispiel eine neue Bibliothek erscheint und eine Applikation 
> > Y diese optional einbinden moechte. 
> 
> 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. Somit muss jedesmal das "Gremium"
gefragt werden ob es nicht vllt. den neuen Test mit aufnehmen moechte.

Das kann _sehr_ aufwaendig werden...

> > Oder wenn sich bestimmte Dinge in einer
> > Abhaengigkeit aendern auf die man testen will/muss. 
> 
> Beispielsweise ?

siehe anderen Teilthread, ein Funktionsname aendert sich, man will die
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. 

Nicht jede Library/Applikation garantiert dir Binaer-Kompatibilitaet
(geschweige denn Source-Kompatibilitaet) innerhalb eines Major-Releases
oder auch nur innerhalb eines Minor-Releases...

> > > Als Anwender muß man eben damit rechnen, daß man immer die neueste 
> > > Version des Buildsystems installieren muß. Auf Veraltetes kann keine 
> > > Rücksicht genommen werden.
> > 
> > Erklaer das mal den Leuten die Debian stable einsetzen wollen, aber
> > trotzdem z.B. von Spamassassin aktuellere Versionen bauen.
> 
> 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?

> > > > s.o. Wie siehts mit der Erweiterbarkeit aus?
> > > 
> > > Gibt es per Definition nicht. Wenn neue Knotentypen benötigt werden, 
> > > muß das Buildsystem weiterentwickelt werden. Als Programmierer sollte
> > > man sich bemühen, mit dem auszukommen, was geboten wird.
> > 
> > Der war gut. Wenn ich eine Applikation entwickle entscheide ich mich
> > fuer eine bestimmte Menge an Abhaengigkeiten. Diese Abhaengigkeiten
> > koennen sich aber ueber die Zeit veraendern, das heisst entweder muss
> > ich _immer_ auf die zur Entwicklung benutzte Version der
> > Bibliothek/anderen App dependen oder aber ich nehme ein erweiterbares
> > Buildsystem. 
> 
> 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
in eine neue Versionen des Buildsystems einfliessen koennen, ich muss
also wenn sich meine Abhaengigkeit (also Lib X) in ihrem Binaer oder
Source Interface aendert (sowas passiert manchmal auch zwischen
Bugfix-Releases!) dafuer sorgen dass ich immer auf die "alte" Version
depende, somit koennen Leute die die neue Version wegen was anderem
brauchen meine Applikation nicht nutzen. Ergo vergesse ich dieses
unflexible Buildsystem und suche mir eines aus, das mich nicht
einschraenkt.

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

> 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. 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. 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. Das nehme ich dann raus sobald
ich release... Das ist IMHO nicht ungewoehnlich wenn man seine App
zeitnah mit dem neuen Release der Lib rausbringen will.

> > > Richtig. Es werden klare Interfaces definiert (zB. BSD-sockets), die
> > > entweder vorhanden sind oder fehlen. Ein Paket kann das nun entweder
> > > vorraussetzen (require) oder verzweigen (conditional). Aber es kann
> > > nicht so weitergehen, daß jeder irgentwelche Hacks produziert, 
> > > die irgentwas zu erraten versuchen und mehr schlecht als recht 
> > > funktionieren.
> > 
> > Und wer soll die "Milliarden" moeglichen "Checks" maintainen? 
> 
> Woher genau nimmst Du die Milliarden ?

Das faellt mir ja jetzt erst auf: Du plenkst.

Bzgl. der Milliarden: Was glaubst du warum die in Anfuehrungszeichen
stehen?

> 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. Sicherlich einiges kann "geshared" werden (Groesse eines int,
Architektur, Byte-Alignment usw.) aber vieles eben auch nicht. Und es
gibt ziemlich viele Bibliotheken da draussen auf die man testen kann,
oder bestimmte Programme...

> > Ich sehe durchaus ein, dass es schwierig ist wenn Hinz und Kunz ihre 
> > eigenen Makros definieren die nur auf dem eigenen System funktionieren. 
> 
> "Schwierig" ist arg untertrieben. Autotools ist pure Schlamperei,
> schon konzeptionell.

Da kann ich nix zu sagen, weil ich dazu zu wenig Erfahrung damit habe.
Es wird aber sicher einen Grund haben warum KDE auf was anderes
umstellt...

> > Aber das hat meistens einen entscheidenden Einfluss auf die (Nicht-) 
> > Akzeptanz solcher Applikationen.
> 
> 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... ;-)

> > > Noch nicht. Aber da ich nur die grundlegenden Funktionen verwende
> > > (keine GUI, keine templates, etc) und überhaupt der Code recht
> > > schmal ist, sollte das kein Problem darstellen.
> > 
> > Ich glaube kaum das das so bleiben wird (also das mit dem schmalen
> > Code).
> 
> 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 ;-)

> > Aber nur zu, wenn dein System mal was "kleineres" bauen kann (eine
> > KDE-App) schau ich mir das vllt. trotzdem mal an.
> 
> 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... 

Meine App hat etwas ueber 5K Code-Zeilen (inkl. Kommentare und
Leerzeilen, bin grad zu faul das "rauszugreppen") und die ist noch
nichtmal sauber designed sondern mehr oder minder "zusammengehackt"...

> > PS: Nimm mir meine Kommentare nicht uebel, ich nehme immer alles
> > auseinander, hab schon mit 3 Jahren damit angefangen ;-)
> 
> Kannst Du auch etwas wieder zusammenbauen ? 

Nee, hab 2 linke Haende, deswegen ja auch das auseinandernehmen (Marke
fallen lassen und so) ;-) 

Naja, fuer's auf und zuschrauben des Rechners reichts grad noch.

Andreas

-- 
You display the wonderful traits of charm and courtesy.



Reply to: