Re: ein neues buildsystem --> autotools endlich abloesen
On 07.03.06 08:46:32, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > On 06.03.06 18:04:14, Enrico Weigelt wrote:
> > > * Andreas Pakulat <apaku@gmx.de> schrieb:
> > Frag mich mal in ner Woche nochmal, dann muss ich "nur noch" fuer
> > meine Komplexpruefung lernen...
>
> hmm, was hast Du denn noch vor Dir ?
o.g. Komplexpruefung (Pruefung im Hauptfach ueber die letzen 2 Jahre)
und dann das Diplom schreiben.
> > 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).
Bei ez-setup passiert genau dass, allerdings sorgt es halt "irgendwie"
(wie gesagt hab da noch nicht soo reingeschaut) dafuer dass das Package
trotzdem als import pack1 verfuegbar ist.
> > > 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 ?
Bei GUI's? Ich glaube da ist man noch nicht so weit...
> > > > > 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 ?
Das war auch so ziemlich das einzige was mir einfiel. Dann brauchst du
ja auch keine QObject-Hierarchie. Ein QObject wird ja nur automatisch
geloescht wenn es in einer QObject-Hierarchie steckt. Sobald du eines
ohne parent erzeugst musst du das selbst loeschen oder halt einen GC
drauf ansetzen (sofern das moeglich ist).
> > > 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.
Das Problem ist da auch nicht das build-System, sondern eine Aenderung
zwischen 6.8.2 und 6.9.0. Das Auffinden ist aber wohl aufgrund des
mangelnden Interesses von upstream etwas schwierig, da man wohl den
alten nicht-modularen Tree zum testen der verschiedenen Aenderungen
nehmen muss...
> > > > > > 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 ...
Oder ich nehme fuer C++ Qt-SQL. Ist auch nix anderes als eine abstrakte
API. Das besondere zumindestens bei JDBC, DBI und auch bei python's
DB-API ist das sie zum Basisumfang der Programmiersprache bzw. deren
Implementierung gehoeren. Das ist bei C++, PHP, C und vllt. noch ein
paar anderen nicht der Fall. Dort muss man sich halt ein passendes
Add-On suchen, ob es nun unixODBC ist oder Qt-SQL.
> > > 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.
Die Widgets brauchen ihre eigenen Datentypen, z.B. QDate, QString usw.
> Oder greift man in QtSQL über Widgets auf die DB zu ?!
Nein. Aber die Qt-SQL API liefert als Ergebnis einer Anfrage direkt Qt's
Datentypen fuer Dates, String usw. die ich direkt an die Widgets
weitergeben kann. Qt nimmt mir hier die Konvertierung ab. Ich vermute
mal die C++-Variante von unixODBC liefert mir STL-Typen zurueck, da
ist die Konvertierung im Falle von string<->QString noch recht einfach,
im Falle von QDate nicht mehr direkt moeglich (aka implizit).
> > > > > 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 ?
s.o. um die Qt-eigenen Datentypen nicht selbst in der Anwendung
konvertieren zu muessen. Das ganze natuerlich nur wenn man auch Qt
widgets hat, wer Qt-SQL nur fuer die DB-Anbindung benutzt macht IMHO
tatsaechlich was falsch, besonders wenn er dann die QT-Typen in eigene
oder STL-Typen umwandelt...
> 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 ...
Ja, aber wieso soll der Anwendungsentwickler den selbst schreiben
muessen? Ausserdem hast du dann wieder zig-tausend Inselloesungen, weil
jeder es ein wenig anders macht...
Andreas
--
Today is the first day of the rest of your life.
Reply to: