Hallo, On Thu, 15 May 2003, Ralf Corsepius wrote:
Am Mit, 2003-05-14 um 23.12 schrieb David Haller:
On Wed, 14 May 2003, Stefan Onken wrote:
am Mittwoch, 14. Mai 2003 um 17:10 schrieb David Haller [..]
webserver:~/000/qmailadmin-1.0.6 # ./configure [..] --includedir=/home/vpopmail/ --libdir=/home/vpopmail/
--libdir=DIR object code libraries in DIR [EPREFIX/lib] --includedir=DIR C header files in DIR [PREFIX/include]
Du solltest also
--includedir=/home/vpopmail/include --libdir=/home/vpopmail/lib
das ist nun interessant, da ich das GENAU anders verstanden habe. Ich dachte ich geben den PREFIX ein, und /lib und /include haengt er selber an.
Nein. Doch.
Nein. Wie du unten selbst schreibst. Das PREFIX in der Frage von Stonki oben bezog sich auf das "PREFIX" in der Defaultangabe von --libdir=. Und er dachte, es reicht, wenn man den "PREFIX"-Teil von --libdir, z.B. "--libdir=/blubb" angibt und dies dann automatisch noch um "/lib" zu "/blubb/lib" ergaenzt wird. Du hast dich aber natuerlich auf das PREFIX von --prefix=/blubb bezogen und das wird ja dann automatisch zu libdir='${prefix}/lib' -- es sei denn, man setzt libdir explizit mit --libdir=...
Das "PREFIX" in den Angaben der Defaults fuer die Optionen ist ein Platzhalter fuer die jew. gueltige prefix, die man evtl. angegeben hat oder die eben per default (meist /usr/local) gesetzt wurde. Nein, mit PREFIX ist hier der Wert der mittels --prefix=PREFIX übergeben wird, gemeint.
Das meinte ich. War bloed formuliert. Das PREFIX bei den --*dir Optionen steht fuer das PREFIX das (evtl.) durch --prefix=PREFIX uebergeben wird oder eben (ohne --prefix) fuer die default-prefix. [..]
Die Expandierung findet dann erst im generierten Makefile statt Ja.
bzw. u.U. (in seltenen Faellen) sogar erst von der von make aufgerufenen shell... Das wäre ein Bug.
Wieso? *g* Und u. bes. U. kann das sogar sinnvoll sein *eg*. z.B. um einen Shell-Befehl zu definieren, der dann erst in der shell in einer Regel expandiert werden soll. Schliesslich kann man mit make auch mehr als nur kompilieren, und bei anderen Sachen braucht man sowas eventuell. [..]
Besser ist, wenn man in dem Falle ggfs:
./configure --prefix='/blubb' --libdir='${prefix}/lib'
usw. verwendet, Hmm, es macht in sauberen Konfigurationen keinen Unterschied.
Genau. Das emuliert ja den Default, wo dann im Makefile landet: prefix = /blubb libdir = ${prefix}/lib Dann reicht es, ein make prefix="/bla/blubb" install zu verwenden und die make-Variable 'libdir' expandiert unter "Verwendung" von ${prefix} zu '/bla/blubb/lib' ;)
Also: '--libdir' sollte man nur verwenden, wenn es von '/lib' abweicht: Nein: --libdir muss man dann verwenden, wenn es von ${prefix}/lib abweicht.
Stimmt. [..]
Wie gesagt: includedir und libdir beziehen sich auf die Orte, an die hininstalliert werden soll -- nicht auf die evtl. einzubindenden Libs... Genau.
Dafuer gibt's ggfs. die Optionen '--cflags=' bzw. '--libs' Nein.
Derartige Flags werden von configure-Scripten normalerweise nicht angeboten.
Hab ich schon oefters gesehen...
Wenn doch, hat entweder der Autor der Scripte nicht verstanden, wie configure-Scripte funktionieren, oder aber es handelt sich um "Convenience-Optionen" zur Behandlung von Sonderfällen (--enable-<xxx>-[cflags|libs]=...).
Nein.
(IIRC) bzw. Umgebungsvariablen (CFLAGS/CPPFLAGS/LDFLAGS/LIBS/LDADD u.a., naeheres muss man ggfs. im Makefile nachschauen). ./configure --help sollte sagen welche Umgebungsvariablen verwendet werden (Ist bei autoconf-2.5x generierten configure-Scripten der Standard, bei autoconf-2.1x generierten configure-Scripten nicht)
Im Regelfall sind dies CFLAGS, CPPFLAGS, LDFLAGS.
Ja. Die o.g. Optionen dienen in den Faellen als _Alternative_ zu diesen Umgebungsvariablen. Es sind dann aequivalent: $ export CPPFLAGS="-I/blubb"; ./configure $ CPPFLAGS="-I/blubb" ./configure $ ./configure --cppflags="-I/blubb" Die letztere Variante halte ich eigentlich fuer prinzipiell auch sinnvoll. Welche "Variante" "gewinnt" wenn man beides gleichzeitig verwendet habe ich nicht getestet, vermutlich aber die Option.
LIBS und LDADD kommen normalerweise nicht aus der Umgebung.
Ja. -dnh -- == Re: Exchange's mailbox format == I hope that's not UI -- but the proper term is a "Jet database", accessed through the "Jet engine". A fitting name, considering that it sucks and blows. -- Felix