[Allegro] Compilierungsprobleme mit atools

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

wie bereits erwaehnt ist die Compilierung einiger Pakete derzeit
ein Blindflug, weil wichtige Dateien fehlen.

Es ist mir gelungen, atools unter Cygwin und Linux (OpenSuse) zu
rekonfigurieren, indem ich dessen configure.in (das wohl besser
configure.ac hiesse) in das atools-Verzeichnis kopiert und darin
AC_CONFIG_FILES angepasst habe (anderes sollte auch anpassenswert
sein, etwa das "avanti,29.12a", was auch fuer das "os"-Demo nicht
ganz stimmig gewesen sein duerfte).

Zunaechst auf ../ac15 und ../aindex, das mochte autoconf aber nicht.
Nach Auschecken einer Kopie in Unterverzeichnisse kam ich dann
langsam dahinter, dass die "benoetigte separat-Bibliothek aindex"
(oder so aehnlich im README) nicht aindex ist, sondern in Form
von Kopien als ai*.c / ai*.h im atools-Verzeichnis direkt
vorliegt. Echtes Dual-use fuer C und C++ sieht m.E. anders aus,
wenigstens ein Unterverzeichnis muessste doch moeglich sein...
Und dass "ac15" C++-Quellen enthaelt, und daher nichts mit dem
"Classico"-Allegro-C (von 1995 oder heute) zu tun hat, fand ich
auch ueberraschend.

Mit nur noch
AC_CONFIG_FILES([Makefile])

in configure.ac und

autoreconf --force -m

bekomme ich dann eine halbwegs funktionierende Umgebung, nach

make distclean

(und ggfls. Wiederholung von autoconf / configure / make distclean, bis
das make distclean sauber durchlaeuft)

[Hier erreicht dann der saubere Zustand, den ich bei einem Checkout
erwarten wuerde]

und erneutem

./configure

jeweils funktionierende Makefiles.

configure liefert einige Warnungen zu strcasecmp und verlgeichbarem,
das ist erst einmal harmlos, weil strcasecmp von atools gar nicht
genutzt wird (nur allegro.hpp aus ac15 definiert stricmp darueber,
aber ac15 wird ja gar nicht genutzt) und die Meldung also nur ein
Artefakt der nicht angepassten configure.ac ist.

Ursache der Warnungen scheint ein ziemlich wildes Einbinden von sowohl
string.h als auch strings.h zu sein.

Unter Cygwin bekomme ich allerdings einen fatalen Abbruch bei
compil.o bei der Funktion stricmp unter Hinweis auf eben jene Funktion
strcasecmp. Das liegt daran, dass auf dieser
Plattform string.h ein

#ifndef stricmp
#define stricmp strcasecmp
#endif

enthaelt (aber compil.c es allgemein fuer alles ausser WIN32 aktivieren
will bzw. es auch nicht per Header vorankuendigt).

MSDN sagt zu stricmp etc., dies seien deprecatete POSIX-C++-Funktionen und man
solle _stricmp etc. aus ISO C++ nutzen. (C-Erweiterungen finde ich leider
nicht im MSDN, "Visual C" scheint nur ein eher wenig erwaehnter Untermodus
von "Visual C++" zu sein? oder stammt das stricmp aus der Borland-Welt?),
das sind fuer mich jedenfalls zwei Gruende, warum stricmp keine Glueckliche
Wahl ist.

strcasecmp scheint je nach Unix-Variante in string.h oder strings.h definiert
zu sein. Die Posix-Variante hat nur in der Posix-Lokale definierte Werte,
die Linux-Variante ist anscheinend ueber tolower implementiert und duerfte
auch Probleme mit localen haben. [Cygwin definiert strcasecmp via _stricmp
in platform.h]

Aber auch bei _stricmp (string.h bei Microsoft) ist ein voriges setlocale
erforderlich und es gibt einen Hinweis darauf, dass _stricoll wohl die
geeignetere Funktion sei.

Ich weiss noch nicht, wofuer atools die Funktionen einsetzt (Suchbegriffe
bei srch, Aufsuchen von Dateinamen?), aber bevor man das Wirrwar aus
verschiedenen Formen der deprecatedness loesen kann, sollte man ueber
generellen Ersatz der Aufrufe durch etwas, das dem Einsatzzweck gemaesser
ist, nachdenken...

viele Gruesse
Thomas Berger