[Allegro] acon und GNU Toolchain

[Thomas Berger]

Liebe Liste,

ich habe ein SVN-Repository aufgesetzt

https://svn.extra.gymel.com/repos/buildsys/acon-gnu/trunk

(sollte anonym lesbar sein), das die fuer das Compilieren
von acon in einer GNU-Autotools-Umgebung benotigten Dateien
enthaelt: configure.ac und Konsorten, sowie als "Externals"
Referenzen auf drei von mir angepasste Schnappschuesse der
Braunschweiger Repositories zu ac15, aindex und acon
(jeweils Branch "autotools-scratchpad", das uebliche "allegro"-
Passwort ist erforderlich):

Dabei sind v.a. alle Conditionals WIN32, LINUX, UNIX so umgearbeitet,
dass die vom Compiler automatisch gelieferten _WIN32 und _MSC_VER
genutzt werden, die autoconf ermitteln kann. Und noch ein paar
Aenderungen, damit die Compilierung auch unter neueren gcc-Versionen
immerhin nicht abbricht.

Derzeit ist ein Build nur aus dem Hauptverzeichnis moeglich
(die separaten configure's aus den Unterverzeichnissen acon,
ac15, aindex sind geloescht, wegen der Interdependenzen
ist ein isolierter Aufbau von libac15.a und libaindex.a auch
nicht prioritaer).

Vorgehensweise: "Auschecken" in ein frisches Verzeichnis
("acon-gnu", wird angelegt):

svn co https://svn.extra.gymel.com/repos/buildsys/acon-gnu/trunk acon-gnu
cd acon-gnu

[bzw.

cd acon-gnu
make distclean
svn update
]

und dann

./configure
make

Compilierung getestet habe ich unter der aktuellen Version von
Ubuntu (32bit) und Cygwin (stets 32bit).

WARNUNG: Was als compiliertes acon bzw. acon.exe herauskommt, duerfte
hoechstwahrscheinlich nicht korrekt ablaufen, denn an einigen Stellen
habe ich drastisch in den Typ von Variablen eingegriffen (es gab z.B.
"BOOL" mit mehr als zwei Werten, oder Probleme damit, dass der Zaehler,
der die Anzahl der ausgegebenen Bytes mitzaehlt, vom Typ RECNR war,
umgekehrt duerften echte Satznummern derzeit evtl. des oefteren nicht
vom TYP RECNR sein: Dafuer muessen erst noch konsequent alle Compiler-
Warnmeldungen untersucht und durch Aenderungen im Quelltext der
Allegro-Module abgestellt werden. Gewisse Dinge sind fuer mich noch
absolut mysterioes, etwa warum ausgerechnet fuer "UNIX" ein explizites,
nicht in Standard-Headern gelieferte Extra-Flag O_DENYNONE fuer
Dateioeffnung definiert wird, das es eigentlich nur bei Turbo-C gegeben
hat bzw. MS-DOS oder FAT16-Modi betrifft...)

Dennoch ist das Erreichte m.E. ein Fortschritt, weil es reproduzierbare
Ergebnisse (ohne vorheriges Umtuefteln von Compileroptionen in
Makefiles) erlaubt.

Sobald die in diesem Branch generierten acons korrekt laufen und
die Quellen exakt so auch in MSVC funktionieren, werde ich die
bis dahin in trunks der drei Module angefallenen Aenderungen
nachvollziehen und vorschlagen, meine branches in den trunk
einzuarbeiten. Urlaubsbedingt wird das aber noch einige Wochen
dauern, bis es so weit ist.

viele Gruesse
Thomas Berger