Re: ein neues buildsystem --> autotools endlich abloesen
On 06.03.06 18:04:14, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > > Ich denke, daß solch ein Projekt für alle Distros nützlich
> > > sein dürfte, da diese dann nicht mehr ihre eigenen Patches pflegen
> > > müssen. Demzufolge sollten dann auch aus den einzelnen Distros
> > > hinreichend viele Leute mitmachen.
> >
> > Dann solltest du mal ein entsprechenden Proposal auf die
> > Distro-devel-Listen setzen und schauen wie die Resonanz ist.
>
> Magst Du mir bei der Formulierung helfen ?
> Hast ja immerhin schon einige gute Ideen gebracht :)
Weiss nicht ob ich da so geeignet bin... Frag mich mal in ner Woche
nochmal, dann muss ich "nur noch" fuer meine Komplexpruefung lernen...
> > Allerdings gibts auch teilweise Probleme, z.B. bei Python Packages.
>
> Mit python kenn ich mich nicht aus. Wo genau gibt es Probleme ?
Python bringt die sog. distutils mit, die zwar die Installation des
Python-Packages vereinfacht, aber keinerlei Parallel-Installation
mehrerer Versionen erlaubt, sofern nicht jeweils die volle Version
(inkl. Minor und Bugfix Nummer) als Paketname benutzt wird. Im
Normalfall will man so ein Package aber mittels
import pack1
nutzen und nicht
import pack1-0.3.41
ez-setup ist da eine Loesung, es baut da auf distutils auf und kann
bei Bedarf Dependecies (die auch mit ez-setup installiert werden
koennen) ausm Netz laden. Ausserdem sorgt es dafuer dass immer die
zuletzt installierte Version als "pack1" verfuegbar ist. Das ganze ist
aber natuerlich Python-Spezifisch und ich weiss auch nicht wie das
"behind-the-scenes" funktioniert.
> > Wenn die nicht ueber distutils/ez-setup sondern mit anderen Methoden
> > (z.B. PyQt nutzt selbstgeschriebenes configure.py und daraus generierte
> > Makefiles) installiert werden wird eine Parallelinstallation von
> > verschiedenen Versionen erschwert.
>
> Aha, also wieder ein Mangel an einem ordentlichen Buildsystem nebst
> sauberer Modellierung, bzw. desssen konsequentem Einsatz ?
Buildsystem bei interpretierten Sprachen ist ja etwas "bloed",
allerdings braucht man das natuerlich fuer die Python-Erweiterungen die
in C geschrieben werden...
Ein Installsystem dagegen das braucht man, weil Python eben die Packages
in bestimmten Pfaden erwartet
> > > Grade bei KDE verstehe ich nicht, warum man sich immer gezwungen
> > > sieht, solche "großen Würfe" machen zu wollen.
> >
> > Weil eben nur eine begrenzte Anzahl Entwickler da sind und diese
> > schaffen es nicht frueher. Uebrigens soll die KDELibs API bis Ende des
>
> Wäre doch grade ein kontra-Argument ;-)
> Mir ist zB. nicht ganz klar, warum KDELibs ein Paket und nicht mindestens
> zehn verschiedene ist.
Hmm:
andreas@morpheus:~>ls /usr/lib/libkde* | grep so$ | grep -v kdeinit
/usr/lib/libkdecore.so
/usr/lib/libkdefakes.so
/usr/lib/libkdefx.so
/usr/lib/libkdeprint_management.so
/usr/lib/libkdeprint.so
/usr/lib/libkdesasl.so
/usr/lib/libkdesu.so
/usr/lib/libkdeui.so
Also, prinzipiell ist das schon so. Du kannst auch kdelibs-X.Y.Z.tar.bz2
runterladen und z.B. nur kdecore bauen und installieren. AFAIK auch
schon in KDE3.
Oben fehlen uebrigens auch gleich noch libkio und libkparts aus
kdelibs...
> > > Man hat manchmal ein Eindruck, daß es sich um ein riesiges
> > > Mammut-Projekt, anstatt vieler einzelner handelt.
> >
> > Das ist ja in gewisser Weise auch richtig, weil zu einem KDE-Release
> > eben ein komplettes DE geliefert werden soll.
>
> Von solchen Ansprüchen sollte man sich verabschieden, wenn man nicht
> genau in die Windows-Falle laufen will ...
Darueber gibt es verschiedene Ansichten. Ich bin nicht unbedingt geneigt
dir zuzustimmen, wir muessen das hier aber nicht weiter ausdiskutieren.
> > > Übrigends einer der wesentlichen Gründe, warum ich nichts
> > > von KDE halte. Bei GNOME scheint mir das bei weitem nicht so schlimm,
> > > obwohl einige Paketen (zB. glib+gtk) auch schon viel zu überzüchtet
> > > sind.
> >
> > Auch kdelibs besteht aus mehreren Teilen. Allerdings lassen die sich
> > nicht einzeln, losgeloest von KDE benutzen. Jedenfalls nicht in KDE3.
> > Fuer KDE4 ist aber geplant eine strengere Trennung in "Core", "Ui" usw.
> > vorzunehmen, so dass KDE-Technologie auch ausserhalb reiner
> > KDE-Anwendungen genutzt werden kann (z.B. KIO).
>
> Na da bin ich mal hochgespannt. Große Erwartungen hab ich da
> allerdings nicht.
Na dann kanns ja nur ne positive Ueberraschung werden ;-) Ich erhoffe
mir in der Tat bestimmte KDE-Techniken (wie KIO) ausserhalb von KDE
nutzen zu koennen. Und vllt. endlich mal ein vernuenftiges
MDI-Tab-Framework (KMDI ist ja der letzte Schrott).
> > > Mir scheint, es liegt dem ein Streben nach einer superlativen
> > > eierlegenden Wollmilchsau zugrunde. Evtl. resultiert dieses wiederum
> > > aus dem Großgruppen inherenten Drang zur Gleichschaltung ...
> >
> > Das gilt IMHO im DE-Bereich allgemein. Man will nunmal das ultimative DE
> > fuer alle herstellen. Ja das ist ein Streben nach Windows-Aehnlichkeit
> > und nein ich finde das nicht immer gut.
>
> IMHO eine Sache die man besser bleiben lassen sollte. Diesen Anspruch
> kann man ohnehin nicht erfüllen, es sei denn, die Maschinen lernen
> denken und die Menschen hören völlig damit auf.
Jupp. Da muss ich dir tatsaechlich zustimmen. Wobei ich da aber Gnome
"weiter vorne" sehe als KDE. Gnome versucht zu viele Dinge vor dem User
zu verstecken um ihn ja nicht zum Denken anzuregen.. Bei KDE lief vor
einiger Zeit eine Diskussion darueber wie man die Konfiguration von
Applikationen und so Dinge wie Toolbars weniger unuebersichtlich und
fuer Anfaenger geeignet darstellt, ohne den Fortgeschrittenen Steine in
den Weg zu legen. IIRC ist das ganze irgendwann mehr oder minder
versandet, die von vielen befuerwortete Option war nur die
wichtigsten/am haeufigsten genutzten Dinge direkt sichtbar zu haben und
fuer alles andere sowas wie einen "Advanced"-Tab (man stritt sich ueber
die genaue Namensgebung) einzufuehren.
> > > > Also hast du doch ne Klon-Maschine zumindest fuers QM.
> > >
> > > Nein, aber ich habe einige grundlegende Methodiken und Prinzipien.
> > >
> > > Sagt Dir "design by contract" etwas ?
> >
> > Jupp. Ich hab ja Softwaretechnik gehoert *bruest* ;-) Im Ernst mir ist
> > prinzipiell schon klar was du meinst. Ich denke ein Problem duerfte
> > sein, dass dies nicht fuer alle (alteingesessenen) Entwickler gilt. Und
> > der Mensch ist von Natur aus traege, er lernt keine neuen Kunststuecke
> > mehr (oder nur sehr ungern).
>
> Auf die Faulheit anderer nehm ich aber keine Rücksicht (es sei denn
> vielleicht, ich werde bezahlt dafür ;-))
Ja, ich sehe nur eben das Problem, dass man dann alle moeglichen libs
selbst patchen muss (und mit selbst meine ich nicht 1 sondern eben das
angesprochene QM-Projekt). Je nach dem wieviele "kaputte" Libs und
"faule" Alt-Entwickler es da draussen gibt (da hab ich weder
Erfahrungswerte noch Zahlen) koennte das aufwaendig werden (vllt. zu
aufwaendig).
> > > Weder widgets noch andere
> > > komplexe Typen haben hier etwas zu suchen - das kommt in eine
> > > andere Library und ggf. sogar in ein separates Paket.
> >
> > UI ist in libQtGui, dann haben wir noch libQtXml, libQtNetwork und
> > libQtSql.
>
> ACK. Allerdings wäre da sicherlich QtGUI noch weiter zu splitten.
Ich glaube kaum, man koennte den MVC-Kram noch rausholen, alles andere
sind dann wirklich nur noch Widgets. Was genau in welchem Modul ist
weiss ich so ausm Kopf aber auch nicht. Wenn dich das weiter
interessiert mach ich ne Liste (per PM).
> QtXml würde sinnvollerweise nur ein Wrapper auf eine schlankere,
> bewährtere Implementation (zb. expat) darstellen. Damit wird Code
> minimiert und es gibt weniger Chancen auf Bugs.
Qt's XML Implementierung ist IMHO auch reichlich unbenutzbar, ausser
vllt. um ein paar Konfigurationsdateien, oder nicht komplexe
Projektdateien zu lesen. Insbesondere das DOM-Zeug. Mit QT-SAX hab ich
noch nix gemacht.
> > Eventuell noch einige Stellen an denen, Dialoge auf dem Heap erzeugt
> > werden, aber noch in derselben Funktion wieder geloescht werden
> > (was aber auch Bloedsinn ist, da Qt dafuer ein passendes Flag
> > bereithaelt - DeleteOnClose)
>
> Solche Automatismen sind ja schön und gut, bergen aber unnötige
> Komplexität. Mit einem GC kann das alles in einem Abwasch erleidgt
> werden.
Der hat aber wohl auch ne gewisse Komplexitaet, davon abgesehen das ein
QObject ja eh schon eine Liste der Kinder hat.
> > > und damit auch die Fehlermöglichkeiten und damit verbundenen
> > > Arbeitsaufwand, massiv zu reduzieren.
> >
> > Hmm, QObjects und alle UI-Elemente sind bereits mit GC ausgeruestet.
> > Zumindestens in der einfachen Form, dass sobald das Elternobjekt
> > verschwindet sie auch geloescht werden.
>
> Sehr schlechte Idee. Vielleicht fallen Dir die Gründe selbst ein.
Hmm, mein Kopf laesst mich grad im Stich. Kannst du mir erklaeren was du
meinst, bitte?
> > So ein Monster ist KDE im Speicher glaube ich gar nicht (mehr),
> > OOo und X11 selbst druecken (hier jedenfalls) viel eher.
>
> Über OOo will ich mich garnicht erst auslassen ...
:-)
> X11 ist dank der Modularisierung auf einem guten Weg der Gesundung,
> ich trage da auch meinen kleinen Teil dazu bei :)
Tja, solange die nicht ihre Probleme mit dem radeon-Treiber und Xinerama
in den Griff kriegen kann ich davon (leider) nicht profitieren..
> > > Genau hier haben wir ja ein massives Problem in gängiger SWE:
> > > Es wird viel Zeit damit vergeudet, irgentwelche memleaks zu finden,
> > > die bei sauberer Strukturierung (und dazu gehört ab einer gewissen
> > > Graphenkomplexität auch ein GC) grundlegend vermieden würden.
> >
> > Was ich von GC immer hoere ist, dass es die Programme langsamer macht.
>
> "Geh nicht in den dunklen Wald, denn dort erwarten Dich schlimme Dinge" ...
>
> Man muß nicht jeden Unsinn glauben, der irgentwo verbreitet wird,
> besonders wenn er irgentwelchen Voruteilen oder religiösen Ansichten
> entspringt ...
Ich hab nicht gesagt das ich das glaube, nur das ich das bisher immer
hoere. IIRC hatte ich in "irgendeiner" Vorlesung auch mal einen Absatz
dazu gehoert, da war davon die Rede das es auf die Implementierung
ankommt und bestimmte Varianten nahezu keinen Overhead haben. Wie gesagt
ich hab davon nicht sooo viel Ahnung...
> > > > 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.
> > >
> > > Eierlegende Wollmilchsau. Man baut eine 5te Struktur, damit man die
> > > vier existierende nicht verstehen muß ... irgentwie widersinnig.
> >
> > Nunja, man kann die von Qt definierten Datentypen weiterverwenden und
> > muss sich nicht mit den diversen DB-Lib-API's rumaergern.
>
> Wieso rumärgern ?
Du musst bei Unterstuetzung von mehr als 1 DBMS immer auch mehr als 1
API "lernen".
> Wo kann man denn bei einer SQL-Anbindung nennenswert von einem GUI-
> Toolkit profitieren ?
Wenn du eine GUI baust die Daten aus einer SQL-DB holt/reinschreibt...
Es soll Leute da draussen geben die machen sowas ;-)
> > > Okay, wenn man schon unbedingt schon ein paar Qt-Konzepte haben will
> > > (zB. die Signals) in einer SQL-Library braucht (warum auch immer ...),
> >
> > Ich glaube weniger Signals, aber z.B. Qt Datentypen wie QString,
> > QByteArray, QDate. Ich muss ansonsten die Konvertierung von char* selbst
> > durchfuehren, das nimmt mir Qt an der Stelle ab.
>
> Dafür reicht ja wohl ein kleiner Wrapper aus, der auf eine
> bewährte Bibliothek setzt. Dazu muß man nicht alles neu programmieren.
Du meinst so wie Qt-SQL? Mag mich ja irren, aber der Hauptteil davon ist
nix weiter als ein paar Interfaces und dazu Plugins die die jeweiligen
DB-Lib-API's auf die Interfaces umsetzen. Bei JDBC ist's ja nix anderes,
oder ODBC.
> > > warum dann nicht ein separates Qt-SQL, das auf Qt aufbaut, und evtl.
> > > sogar gleich vorhandenes und erprobtes (unixODBC) wiederverwendet ?
> >
> > s. Qt4, das gibts jetzt. ODBC-Treiber haben sie IIRC auch.
>
> Ja, nach 10 Jahren ... ;-)
ODBC gabs in Qt3 auch schon.
Nein, du musst Qt(3,4,...) nicht moegen, mir gefaellts aber schon...
Andreas
--
You attempt things that you do not even plan because of your extreme stupidity.
Reply to: