Moin, On Mittwoch, 31. Oktober 2007, Micha Lenk wrote: [...] > > #>PKG_CONFIG_PATH=/opt/gwen/lib/pkgconfig ./configure > > > > ..., natuerlich alles in einer Zeile, und dennoch hat mir da pkg-config > > zwischengefunkt. > > Bist du dir ganz sicher, dass das aufs gleiche herauskommt? [...] Ja. Wenn man das wie Du in einem eigenen Befehl macht, muss man es mit "export" machen (weil die ENV sonst nicht fuer die naechsten Befehle gesetzt wird).
Wenn ich es aber direkt dem Befehl voranstelle, gilt die ENV fuer genau den angegebenen Befehl, danach nicht mehr. Das reicht ja auch, denn pkg-config wird ja nur aus dem ./configure heraus aufgerufen. [...] > Wieso? Die "seltsamen includes" kommen doch nicht irgendwo her, sondern > aus genau der selben Installation wie sonst auch gwenhywfar-config. Wenn > die .pc-Datei fehlerhaft ist, kann man das doch kaum pkg-config > anlasten. Das ist in meinen Augen auch kein "Hinbiegen", sondern ein [...] Es geht nicht um fehlerhafte configs, sondern darum, dass PKG_CONFIG in meinem Fall einfach die Infos aus der Standard-PC-Datei genommen hat (gwenhywfar.pc im Standard-Verzeichnis), was ich aber so nicht haben wollte (deswegen habe ich ja PKG_CONFIG_PATH angegeben. Und es gab keinerlei Fehlermeldung (was auch voellig normal ist, denn irgendwo hat pkg-config ja die PC-Datei gefunden, und dass es nicht die ist, die ich haben wollte, kann es ja nicht wissen). Das Ergebnis war, dass ich includes und libs drin hatte, die ich nicht haben wollte, und erst im anschliessenden Compiler-Lauf nach ca 5 Minuten gab es dann Fehlermeldungen, weil eine alte Version von Gwen included wurde. [...] > durchaus verbreitetes aber eben alternatives Verfahren, um C-Flags und > Linker-Flags installierter Bibliotheken zu ermitteln, das <rant>ohne > Verschmutzung der Menge der im Pfad installierten Programme</rant> > auskommt. [...] Grrr... Wie soll ich das denn nun wieder verstehen?? Es ist doch bisher ganz einfach: Wenn ich z.B. AqBanking mit dem an /opt/devel installierten GWEN verwenden will, gebe ich bei ./configure einfach an "--with-gwen-dir=/opt/devel". Sollte es da nicht sein, bekomme ich eine Fehlermeldung und Punkt. Dann kann ich nachsehen, ob ich mich vertippt habe oder ob Gwen gar nicht dahin installiert ist. Das funktioniert bisher sehr zuverlaessig, und hier wird ueberhaupt nichts *verschmutzt*! Tatsaechlich wird PATH dabei ueberhaupt nicht veraendert oder ueberhaupt benutzt! Es wird sogar die PATH-Variable ueberhaupt nicht geaendert dafuer, also wo bitte wird hier was verschmutzt?? [...] > > Ich finde *eine* Konfigurationsmoeglichkeit reicht voellig, und die, die > > wir haben, *geht*. > > Aber die Konfigurationsmöglichkeit, die wir haben, wird doch durch die > Erweiterung um pkg-config-Unterstützung garnicht angerührt. Insbesondere [...] Nein, Du willst zusaetzlich zu der bisher eingebauten Moeglichkeit eine andere einbauen, und das finde ich eben nicht sinnvoll. Wir verwenden *eine* Methode, die funktioniert und einfach ist. Da noch zusaetzlich eine weitere Methode einzubauen, finde ich nicht einleuchtend. Wenn "--with-gwen-dir" scheitert, hat das meistens einen guten Grund, und ich will in dem Fall nicht, dass pkg-config mir anschliessend doch wieder etwas falsches heraussucht. [...] > Für mich klingt das so, als soll ein neues Feature, das FOO leistet, nur > deswegen nicht eingebaut werden, weil ein anderes Feature, das ebenfalls > FOO leistet, schon existiert. Für mich ist das etwas unverständlich. [...] Was ist denn daran so ungewoehnlich? Ich muss doch nicht alles einbauen, nur weil es das gibt? Ich nehme das, was schon lange funktioniert, warum soll ich das ohne Not aendern, nur weil es etwas anderes gibt? Ich steige doch jetzt auch nicht auf cmake um, nur weil es im Prinzip moeglich waere und andere da gute Erfahrungen mit gemacht haben? Es mag ja durchaus sein, dass pkg-config so toll ist, dass es jeder verwenden MUSS, aber ich sehe keinen Grund, unser System jetzt zu aendern, wenn es gut funktioniert. Gerade naemlich Basteleien an der configure.ac koennen sich zu einer ziemlichen Frickelei ausweiten (ich habe da leider gerade in der Anfangszeit eine Menge schlechter Erfahrungen gesammelt), ich bin froh, dass es laeuft und tut, was es soll. Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
