Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
> 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...
Ich denke schon :)
> Frag mich mal in ner Woche nochmal, dann muss ich "nur noch" fuer
> meine Komplexpruefung lernen...
hmm, was hast Du denn noch vor Dir ?
<snip>
> > > 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
Ja, unter diesen Bedigungen kann man auch schwer MVCC realisieren.
Es müßte schon die Version im Paketnamen verbacken sein, sonst
wird das immer ein elendes Gefummel (mit Suchpfaden spielen, etc).
<snip>
> > > > 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.
Warum sind das nicht alles eigene Pakete ?!
Was bitte hat SASL mit Drucken zu tun ?!
Das ist genau diese Schlamperei, die solche Projekte übermäßig
fett und schlecht handlebar werden läßt.
Xorg(-mod) ist da mittlerweile deutlich weiter.
<snip>
> > > > 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.
Ist das nicht eine Sache von Stylesheets ?
<snip>
> > 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).
Daß es Arbeit macht, ist mir schon klar. Aber langfristig bin ich
mir sicher, daß sich das unterm Strich lohnt (zumindest wenn noch
ein paar mehr Leute mitmachen). Bisher wird ja extrem viel Zeit
für das Umschiffen von irgentwelchen Bugs verbrannt - diese wäre
konzentriert im QM-Projekt deutlich besser und effizienter eingesetzt.
<snip>
> > > > 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).
Nein, so im Detail interessiert mich Qt ja nicht ;-P
(Ich lebe ja Qt-frei, ernähre mich nur von ungesättigten Libraries)
<snip>
> > 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.
Womit dann auch gleich wieder die Frage nach der Daseinsberechtigung
steht ...
Also hier sieht man doch ganz deutlich den Gleichschaltungsdrang.
<snip>
> > > 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.
Über die Komplexität des GC muß Du Dir keinen Kopf zerbrechen.
Der funktioniert auch in embedded-JVMs recht gut und nimmt Dir
praktisch alle Arbeit beim Speicheraufräumen ab. Jede weitere
Diskussion über irgentwelche dispose-Mechanismen (zb. im QObject)
sind damit überflüssig, weil das Problem mit dem abschließend
gelöst ist. Auf weitere Sicht wieder eine massive Komplexitäts-
und Code-Reduzierung. Aber solang GC's unter den "Real Coderz" als
"akademischer Schnickschnack" verschrien ist, wird sich wohl so
schnell keine Besserung geben ...
<snip>
> > > > 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?
Es könnte sein, daß ein Objekt mehrfach referenziert ist ?
<snip>
> > 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..
Gut, mit solchen Details hab ich mich noch nicht befaßt - ich seh
erstmal zu, daß ich den Xserver in minimalster Form gebaut kriege.
<snip>
> > > > 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...
Richtig. GC ist ein Konzept, kein Programm. Es gibt gute und schlechte.
IMHO ist der boehm-gc für normale Anwendungen hinreichend gut.
Etwas kniffliger wird sowas in verteilten Anwendungen (auf mehrere
Prozesse oder Hosts) oder auch bei multithreading mit harten Echtzeit-
Anforderungen - da muß man schon noch etwas mehr Hirnschmalz investieren.
<snip>
> > > > > 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".
Oder Du nimmst eine abstrakte API. Jede nennenswerte Programmiersprache
hat das. Für C/C++ gibts unixODBC, für perl gibts DBI, für php
gibts PEAR::DB, usw ...
<snip>
> > 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 ;-)
Ich verstehe dennoch das Problem noch nicht ganz ... ich hole Daten
aus der DB (odbc) und packe sie in ein widget (qt), ich reagiere auf
Aktionen (qt) und schreibe Daten zurück (odbc). Sauber getrennt.
Oder greift man in QtSQL über Widgets auf die DB zu ?!
> > > > 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.
Ja, odbc/jdbc ist bereits ein wrapper, wenn man so will (ein recht modularer).
Warum das alles nochmal bauen ?
Okay, ich kann mir ja vorstellen, daß man vielleicht die Ergebnisse
in einer QList und String-Parameter im QString haben möchte, aber
das erfordert doch wirklich nur einen mickrigen 50k-wrapper ...
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: