On Fri, 2003-12-05 at 10:27, Dr. Jürgen Vollmer wrote:

Andreas Kyek

...

Wer kann mir sagen, ich welcher Makrodatei dieses `AM_PATH_PROG_WITH_TEST' definiert sein müsste?

weiss ich zwar auch nicht aber ein find /usr/include -type f | xargs grep AM_PATH_PROG_WITH_TEST sollte es abliefern. Zur Not noch weitere Verzeichnisse nach /usr/include angeben. Falsche Baustelle ;)

Hier beschwert sich aclocal über fehlende m4-Macros, die innerhalb eines configure.in-Scripts verwendet werden. Macros mit Namensprefix AM_* sind für automake selbst reserviert und sollten in /usr/share/aclocal-<automake-API-Version>/*.m4 liegen Da sich die Macros mancher Pakete nicht an die Konventionen halten, könnten solche Macros auch in Macros aus aclocal's User-Macro Verzeichnis (/usr/share/aclocal) gefunden werden. Ein grep bei mir liefert: # grep AM_PATH_PROG_WITH_TEST /usr/share/aclocal*/*.m4 /usr/share/aclocal/po.m4: AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt, /usr/share/aclocal/po.m4: AM_PATH_PROG_WITH_TEST(XGETTEXT, xgettext, /usr/share/aclocal/po.m4: AM_PATH_PROG_WITH_TEST(MSGMERGE, msgmerge, /usr/share/aclocal/progtest.m4:dnl AM_PATH_PROG_WITH_TEST(VARIABLE, PROG-TO-CHECK-FOR, /usr/share/aclocal/progtest.m4:AC_DEFUN([AM_PATH_PROG_WITH_TEST], Gesucht ist hier /usr/share/aclocal/progtest.m4, welches zu gettext-0.12.x gehört. Aber, ... diese Thematik sollte Andreas als "Installer" überhaupt nicht betreffen. Die Tatsache, dass hier aclocal überhaupt gestartet wird, deutet darauf hin, dass * die Quellen an entscheidenen Stellen (Configure-Scripte, Makefiles) editiert wurden (Patchen ist auch editierten) * der Tarball fehlerhaft gepackt ist. * SuSE's rpm Mist baut. * Das rpm.spec fehlerhaft ist. Auf jeden Fall hat Andreas gettext nicht oder in einer falschen Version installiert - Nur, wie oben schon gesagt, wenn das Rpm.spec sauber ist, nicht an relevanten Stellen im Code editiert wurde und der Tarball sauber gepackt ist, sollte dieses Problem gar nicht auftreten. Ralf

On Fri, 2003-12-05 at 12:45, Andreas Kyek wrote:

On Friday 05 December 2003 11:18, Ralf Corsepius wrote:

...

On Fri, 2003-12-05 at 10:27, Dr. Jürgen Vollmer wrote:

...

Andreas Kyek

...

Wer kann mir sagen, ich welcher Makrodatei dieses `AM_PATH_PROG_WITH_TEST' definiert sein müsste?

...

/usr/share/aclocal/progtest.m4:AC_DEFUN([AM_PATH_PROG_WITH_TEST],

Gesucht ist hier /usr/share/aclocal/progtest.m4, welches zu gettext-0.12.x gehört.

[...]

Das wars. gettext hat gefehlt. Leider hatte ich keine Ahnung, in welcher der vielen Dateien in den vielen rpms gerade dieses Makro definiert ist. Installierte aclocal-Macros liegen normalerweise nur an 2 Stellen:

/usr/share/aclocal Die Stelle, an der Pakete ihre Macros installieren sollten. /usr/share/aclocal- Die Stelle, an der automake-APIVERS seine eigenen Macros installiert (aclocal gehört zu automake). Von diesen Verzeichnissen kann es mehrere geben, da automake in unterschiedlichen Versionen parallel installiert sein können. Manchmal findet man die Macros eines Pakets, dass nicht unter /usr installiert ist, auch unter $(prefix)/share/aclocal des Paketes (Bei SuSE soll es z.B. /opt/gnome2/share/aclocal geben). Über den Sinn und Zweck dieser Art der Installation kann man durchaus geteilter Meinung sein ;) Ralf

On Sat, 2003-12-06 at 02:14, Philipp Thomas wrote:

Ralf Corsepius [Fr, 05 Dez 2003 11:18:45 +0100]:

...

* SuSE's rpm Mist baut.

Wenn du den Aufruf von autoreconf aus dem .spec heraus für Mist erklärst, ja. Nun, autoreconf im spec-File halte ich schon für gewagt.

Manuelles autoreconf mit anschliessenden Tests + Patch im src.rpm hingegen kann sinnvoll sein.

Ich weiss, warum ich bei allen Paketen, die ich betreue, so ziemlich als erstes den Aufruf drinhabe. Dazu haben mich Dinge wie z.B. uralte libtool-Makros in aclocal.m4 zu sehr geärgert :-) Und ich ärgere mich über libtool-1.5

und ein autoreconf stellt einigermassen sicher, dass die vom jeweiligen Paket mitgeschleppten Makros einigermassen uptodate sind. Insofern autoreconf denn funktioniert ...

... das tut es aus verschiedensten Gründen aber nicht immer ...

Ja, für den Benutzer, der dieses Paket kompilieren will, bedeutet das etwas mehr Aufwand. Dann sollte das rpm.spec aber auch ein BuildPreReq: autoconf automake gettext libtool enthalten, um User frühzeitig darauf zu stossen.

Trotzdem halte ich die Gefahr, auf irgendwelche Seiteneffekte von autoreconf aufzulaufen (Bugs/Inkompatibilitäten, schmutzige Scripte) für weitaus schwerwiegender, da Du keinerlei Kontrolle darüber hast, ob ein autoreconf funktionsfähige Dateien erzeugt. In einigermaßen sauberen und halbwegs trivialen Fällen wird es gut gehen, doch sobald die Konfiguration nicht mehr trivial ist, wird es "interessant" (Lass mal autoreconf auf gcc los ;) )

Aber wer garantiert dir, dass auf dem System nicht Sachen aktualisiert wurden, die einen autoreconf nötig machen? Welche sollten das sein? Eigentlich sollte keinerlei Notwendigkeit geben, irgendwelche der auto*-generierten Scripte zu regenerieren.

Gut, es gibt Bugs in auto*tool generierten Dateien, die sich *nach* der Installation auswirken könnten, doch wären das Bugs in den Paketen, die sich gefixt gehören (z.B. falsche Pfade in *.la). Diese mittels autoreconf beheben zu wollen halte ich für "die grosse Keule". Ralf

On Sun, 2003-12-07 at 14:49, Philipp Thomas wrote:

Ralf Corsepius [Sun, 07 Dec 2003 08:27:56 +0100]:

...

Nun, autoreconf im spec-File halte ich schon für gewagt.

Ich halte es für deutlich einfacher als automake etc. explizit aus dem spec-file aufzurufen.

[ ] Du kennst den Sinn und Zweck der autotools.

...

Manuelles autoreconf mit anschliessenden Tests + Patch im src.rpm hingegen kann sinnvoll sein.

Und wenn eines oder mehrere der Autotools-Pakete aktualisiert werden den Patch wieder anpassen? Nein danke. Sinn und Zweck der autotools ist, dass Du gar nichts anpassen sollst.

Wenn in einer der Config-Dateien ein Fehler vorhanden ist, kannst Du ihn beheben und einmalig die Autotools drüber laufen lassen sowie den Bug an die Autoren melden.

...

Insofern autoreconf denn funktioniert ...

Zumindest für meine Pakete überprüfe ich das. Wenn autoreconf nicht funktioniert, wird es auch nicht aufgerufen.

...

Dann sollte das rpm.spec aber auch ein BuildPreReq: autoconf automake gettext libtool enthalten, um User frühzeitig darauf zu stossen.

Es sind SUSE-Pakete und der korrekte Weg sie zu bauen ist die Verwendung des mitgelieferten "build" Skriptes. Das mag dir nicht schmecken, ist aber so. Nominiell werden rpms mit rpmbuild (rpm-4) bzw. rpm (rpm-3) übersetzt. Ein sauberes RPM.spec liefert dabei saubere Fehlermeldungen, sollte etwas nicht stimmen. Ein rpm.spec, das während des rpmbuilds stirbt, ist deshalb schlicht und einfach als fehlerhaft einzustufen.

Was die Fa. SuSE in ihre Kommentare in rpm-Specs packt, um hausinterne Scripte (build) anzusteuern, ist deshalb aus RPM-Sicht völlig irrelevant.

...

"interessant" (Lass mal autoreconf auf gcc los ;) )

Solange gcc noch nicht auf die aktuellen Autotools umgestellt ist? Sicherlich nicht! Warum? Du verwendest doch auch sonst autoreconf? Woher weißt Du dass das autoreconf aus zukünftigen auto*tool-Versionen noch funktionionsfähige Dateien generiert?

Du kannst es nicht wissen. Gerade der Wechsel von libtool-1.4 zu libtool-1.5 ist ein Musterbeispiel dafür, wie autoreconf funktionsfähige configure-Scripte vernichten kann. [In libtool-1.5 sind zwar einige schwerwiegende Probleme/Mängel aus libtool-1.4 behoben worden, andererseits sind aber auch neue gravierende Bugs hinzugekommen - Einer davon sorgt dafür, dass ich libtool-1.5 für ein Projekt nicht verwenden kann.]

...

Welche sollten das sein? Eigentlich sollte keinerlei Notwendigkeit geben, irgendwelche der auto*-generierten Scripte zu regenerieren.

Zum Beispiel eine neue Version von libtool? Wozu? Der einzige Grund, libtoolize (bzw. autoreconf) zu einzusetzen, wäre der, dass die im Paket enthaltenen Libtool-Scripte fehlerhafte libs generieren würden.

Derartige Bugs in libtool gab es und rechtfertigt in *diesen Fällen* einen autoreconf-Lauf. In allen anderen Fällen ist es Aktionismus. Ralf

On Mon, 2003-12-08 at 03:25, Philipp Thomas wrote:

Ralf Corsepius [Mo, 08 Dez 2003 00:39:32 +0100]:

...

[ ] Du kennst den Sinn und Zweck der autotools.

Können wir solche dummen rethorische Fragen lassen? Natürlich kenne ich den. Die Frage war durchaus ernst gemeint.

...

Sinn und Zweck der autotools ist, dass Du gar nichts anpassen sollst.

Ah ja, und dann schleppt ein Paket z.B. uralte gnome autoconf Makros mit sich rum, die nicht zur aktuell installierten Version passen. Und wo ist das Problem? Die configure-Scripte sollten trotzdem funktionieren.

Ohne autoreconf, bzw. regenerierung von configure.in knallt das Ganze gewaltig. Was knallt?

Entweder die configure-Scripte funktionieren oder aber Du musst, wie bei allen anderen Paketen auch die dazu passende Versionen der autotools installieren. Nichts anderes verlangen z.B. auch gcc, binutils und gdb. Doch selbst wenn du einen automatischen Update versuchen willst, wäre nicht autoreconf das Tool der Wahl, sondern autoupdate.

...

Nominiell werden rpms mit rpmbuild (rpm-4) bzw. rpm (rpm-3) übersetzt. Ein sauberes RPM.spec liefert dabei saubere Fehlermeldungen, sollte etwas nicht stimmen. Ein rpm.spec, das während des rpmbuilds stirbt, ist deshalb schlicht und einfach als fehlerhaft einzustufen.

Von mir aus ist es das dann halt. Über den Punkt werden wir uns wahrscheinlich nie einigen können. Ja, wie Du weißt, halte SuSE's build Systeme für ein konzeptionell krankes System.

...

Was die Fa. SuSE in ihre Kommentare in rpm-Specs packt, um hausinterne Scripte (build) anzusteuern, ist deshalb aus RPM-Sicht völlig irrelevant.

Mag ja sein, aber für SUSE ist build und das internes Build-System alles andere als irrelevant. Was Du sagst, bedeutet nichts anderes, als dass "SuSE auf rpm pfeift", an den rpm-Standardmechanismen vorbei arbeitet und von End-Usern verlangt, ihr proprietäres System zu verwenden.

Das mit den Attributen Isolationismus, fehlende Weit- und Einsicht oder auch als Ausdruck einer speziellen Kundenfreundlichkeit bezeichnen zu wollen, würde ich nicht für verfehlt halten.

...

Warum? Du verwendest doch auch sonst autoreconf?

Lies noch mal. Ich verwende autoreconf, wo dies möglich ist. Ansonsten werden autoconf/automake eben explizit aufgerufen oder, wo das nicht geht weil der Autor des Packetes meinte, direkt m4 anzusprechen zu müssen, wird eben configure direkt gepatchet.

...

Woher weißt Du dass das autoreconf aus zukünftigen auto*tool-Versionen noch funktionionsfähige Dateien generiert?

Du kannst es nicht wissen. Gerade der Wechsel von libtool-1.4 zu libtool-1.5 ist ein Musterbeispiel dafür, wie autoreconf funktionsfähige configure-Scripte vernichten kann.

Erzähl mir nichts, libtool 1.5 hat auch mir mächtig Kopfschmerzen gemacht. libtool gehört zu den Tools, die tendenziell mehr Probleme schaffen als sie lösen.

...

Einer davon sorgt dafür, dass ich libtool-1.5 für ein Projekt nicht verwenden kann.

Welcher, mal so aus Neugier? Eine Variante des Language-TAG-Problems.

http://mail.gnu.org/archive/html/bug-libtool/2003-04/msg00032.html Vanilla libtool-1.5 sorgt dafür, dass standardmässig immer nach c, c++ und fortran Compilern gesucht wird. Solange man all diese installiert hat und nicht cross-compiliert, ist dies kein all zu grossen Problem. Es werden halt eigentlich nicht benötigte Tools mit hineingezogen. Sobald man aber cross-compiliert und hat z.B. nur einen c-Cross-Compiler, sorgt Libtool dafür, das installierte native C++- und fortran-Compiler statt der entsprechenden Cross-Compiler aufgegriffen werden. Das zerbricht z.B. configure Scripte, die standardmässig C verwenden und bedingt zu übersetzende C++-Code-Teile beinhalten (Von der Machart "Wenn C++-Compiler vorhanden, dann übersetze C++-Wrapper"). Da Libtool-1.5 intern mächtig mit AC_REQUIRE zu tricksen versucht (Und dabei scheitert), ist es nahezu unmöglich ein configure-Script derart zu trimmen, dass die durch libtool verursachten Compiler-Checks an den richtigen Stellen stattfinden um zu verhindern, dass der falsche Compiler aufgegriffen wird oder aber diese ganz zu unterdrücken. Ein potentieller Work-Around wären die Language-Tags, doch gibt es keine offizielle Version von Libtool, die diese unterstützt.

...

Wozu? Der einzige Grund, libtoolize (bzw. autoreconf) zu einzusetzen, wäre der, dass die im Paket enthaltenen Libtool-Scripte fehlerhafte libs generieren würden.

Oder z.B. das Paket auf einer neuen Architektur gebaut wird, welche von libtool nicht erkannt wird? Ja, das wäre auch ein Grund. In einer Reihe von derartigen Fällen geht ein autoreconf gut. In einer Reihe von Fällen geht es nicht (Zahlreiche Gnome1-Pakete gehören dazu).

Ralf