Mahlzeit,
(ich bleib auf der Liste wegen Archiv)
Martin Preuss schrieb:
Insbesondere soll sowas wie binreloc von den
autopackage Leuten http://autopackage.org/docs/binreloc/ ja tatsächlich
eine Hilfe sein.
[...]
Ich habe mir das heute mal angesehen, und ich glaube nicht, dass uns das eine
groessere Hilfe sein wird... Zum einen funktioniert das nur auf Systemen, auf
denen "/proc/self/..." vorhanden ist (also z.B. nicht unter Windows), zum
anderen finde ich es unguenstig, wenn jede Library selber bestimmt, wo die
Daten zu liegen haben. Das sollte - so wie in unserem bisherigen Ansatz -
besser der Anwendung ueberlassen bleiben. Ansonsten koennte da vermutlich ein
ziemliches Chaos entstehen, weil dann keiner mehr durchblickt, wo denn
welcher Teil welchen Pfad vermutet...
Oh, ich war vielleicht etwas undeutlich, welche pfade ich eigentlich
meinte: Momentan fand ich den gwen_plugindir Pfad am problematischsten.
Der wird in gwen zur compile-Zeit festgelegt und an alle Anwendungen
ebenfalls zur compile-Zeit weitergegeben. Da kann die Anwendung doch gar
nichts weiter entscheiden -- das ist momentan alles hard-coded. Davon
würde ich gerne wegkommen.
Worum es mir geht, ist doch weniger, dass eine library anstelle der
Anwendung selber über die Pfade bestimmt -- das tun sie momentan eh
eigentlich nicht --, sondern dass die Pfade erst zur Installations-Zeit
gesetzt werden. Auf Windows ist das erledigt, sobald konsequent alle
Pfade aus der registry ausgelesen werden (und da werden die
binreloc-Sachen dann eh nicht benötigt). Das ist in gwen mit meinen
letzten Änderungen nun auch der Fall. Auf Unix haben wir das halt
weiterhin leider nicht, denn u.a. gibt es halt keinen Mechanismus, wo
man gerade zur Installations-Zeit die gewählten Pfade speichern kann.
Deshalb ist das Angebot von den binreloc-Tools, dass man eben erst zur
Laufzeit guckt, wo man denn installiert ist, und da heraus sich also
rekonstruiert, wo denn wohl die anderen Pfade sein müssen. Dafür und nur
dafür sind die binreloc-Sachen IMHO eine interessante Möglichkeit auf Unix.
Unser bisheriger Ansatz mit dem GWEN_PathManager geht schon in die richtige
Richtung, wie ich finde: Zwar koennte hier auch jetzt schon im Prinzip jede
Lib ihre eigenen Pfade setzen, aber das kann die Anwendung durch eigene
Aenderungen an den Pfad-Listen overriden. Damit verbleibt die Kontrolle ueber
die Pfade grundsaetzlich bei der Anwendung.
Im Prinzip ja und gerne, aber was für Fälle hast du hier im Kopf?
Unterschiedliche Pfade konnten lib und Anwendung für die eigenen Sachen
eh schon immer haben, nur das gwen_plugindir, das war die ganze Zeit
bisher festgelegt. Andere Pfade waren doch eh nicht für lib und
Anwendung gemeinsam von Bedeutung, oder?
Was wir aber - denke ich - gebrauchen koennten, waere die Moeglichkeit, den
vollen Pfad zum Executable zu erhalten: Da koennten wir uns die entsprechende
Funktion aus binreloc herauskopieren und in GWEN unterbringen. Wir muessten
dann fuer diese Funktion auch ein Aequivalent fuer Windows haben, aber da ist
es ja einfacher, weil in argv[0] der vollstaendige Pfad uebergeben wird.
Dann koennte man z.B. auch in Verzeichnissen unterhalb des exe-Verzeichnisses
nach Daten/plugins suchen lassen, wenn man wollte (und unter Windows will man
das haeufig).
Könnte man, ja, aber auf Windows würde ich halt eher alle relevanten
Pfade zur Install-Zeit in der registry ablegen und damit ist eh alles
erledigt. Die binreloc-Sachen würden IMHO nur für Unix was ändern. Ach
ja, und wenn wir da was rüberkopieren, dann würde ich schon wie von
denen empfohlen das vollständige header und c-file übernehmen. Würde ein
eventuelles Versionsupgrade vereinfachen...
Gruß
Christian
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Aqbanking-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
