[Allegro] Compilierungsprobleme mit atools

[Thomas Berger]

Lieber Herr Eversberg,

>> wie bereits erwaehnt ist die Compilierung einiger Pakete derzeit
>> ein Blindflug, weil wichtige Dateien fehlen.
>>
> Welche werden denn unbedingt noch gebraucht?

Primaer wohl configure.ac in jedem Projekt. Das darf wohl auch
configure.in heissen (wie bei "os" und "avanti"), vgl.
man autoconf

Es gibt ein Tool namens "autoscan", das ein rudimentaeres configure.scan
liefert als Ausgangsbasis fuer ein eigenes configure.ac, vgl.
man autoscan
Ich musste da mindestens noch AM_INIT_AUTOMAKE, CFLAGS, CXXFLAGS
ergaenzen (alles dem configure.ac des os-Projekts abgeschaut), bei acon
aber muessen auch Header (oder mehr?) aus den anderen Teilprojekten eingebunden
werden: Die sind ggfls in AC_CONFIG_FILES zu ergaenzen womit dann auch ein
 - im README? - zu dokumentierendes Verzeichnislayout vorgegeben ist (derzeit
hardcodiert in Makefile.am?)

aclocal kann damit nun aclocal.m4 erzeugen, automake anschliessend Makefile.in
und Makefile

Es kommen Beschwerden von automake bezueglich einiger standardisierter
Meta-Dateien, die nach deren Spielregeln jedes Projekt haben sollte:

INSTALL
NEWS
AUTHORS
ChangeLog
COPYING
und ein paar Skripte (je nach konkreten AC_Anforderungen in configure.ac:
ist AC_PROG_INSTALL angegeben, wird z.B. auch install-sh eingefordert...)

Letztendlich ist man dann immerhin in der Lage

make clean, make distclean, make maintainer-clean

auszufuehren.

Ich vermute, dass das Resultat von "make distclean", also das, was danach
uebrig bleibt, genau der Umfang ist, der ins SVN-Repository gehoert. Alles
darueber hinausgehende ist definitiv Plattform- und meist sogar maschinen-
abhaengig, man kann einfach nicht erwarten, ein Checkout auf eine beliebige
Plattform zu machen und dabei ein "funktionierendes" Makefile zu bekommen.
Der Umfang im SVN-Repository entspraeche dann einer Source-Distrubtion als
Tarball.

Es /ist/ dann immer noch nicht auszuschliessen, dass gewisse (alle?) Plattformen
eine Umkonfiguration mit den Autotools benoetigen, so dass ein Risiko besteht,
dass per commit staendig andere Versionen der von diesen generierten Dateien
im Repository landen (etwa configure. Und auch aclocal.m4 haengt definitiv von
der fuer die Generierung eingesetzten Version von aclocal ab). Einschraenkung
auf den Umfang von "make maintainer-clean" wuerde auch die aussen vor halten.
Anwender (=Hilfsentwickler), die ohnehin umkonfigurieren muessen, koennen das
dann evtl. guenstiger, aber solche, die evtl. nicht umkonfigurieren muessten,
benoetigen dann zwingend die entsprechenden Tools...

In einem naechsten Schritt waeren dann die ueber diesen Umfang hinausgehenden
Dateien aus dem Repository zu loeschen und in einem Dritten dann ist die
svn-ignore-Liste fuer die Verzeichnisse so zu setzen, dass Zwischenergebnisse
und Endprodukte nicht staendig als "unversioned" gemeldet werden (und durch
ihre Menge den Blick auf eventuell echte Neudateien in den Verzeichnissen
versperren).


>> Es ist mir gelungen, atools unter Cygwin und Linux (OpenSuse) zu
>> rekonfigurieren, ...
> Gut, das sollten wir dann übernehmen. Ich kann Ihnen eine Kennung
> mit Schreibzugriff einräumen. Wir haben ja nicht alle gebräuchlichen
> Plattformen zur Verfügung, noch hätten wir die Zeit, sie alle
> durchzutesten, und an genügend umfassender Versiertheit mit Autotools
> fehlt es auch. Da kommt uns jede Hilfe gelegen und ist ja auch im
> Sinne der OpenSource-Idee. Gerne konfigurieren wir das SVN auch
> nach präzisen und bewährten Vorgaben anders, es ist unvollkommen.

Ich wuerde demnaechst gerne darauf zurueckkommen, muss mir aber
insbesondere erst die Microsoft-Tools aneignen ("Visual" war fuer mich
bislang etwas aus der Sphaere der GUI-Entwickler ;-): Ich sollte
bei Linux etc. betreffenden Aenderungen ja zumindest abschaetzen koennen,
ob dadurch Win32-Builds zerbrechen... Ueberdies waere es mir natuerlich
lieber, erst einmal mit kleinen Aenderungsvorschlaegen anzufangen, dazu
ist es allerdings noetig, etwas so vollstaendiges zu haben, dass es sich
(auf manchen Plattformen wenigstens) compilieren laesst.

Was auf Ihrer Seite allerdings m.E. recht zuegig realisiert werden
sollte, ist das Einziehen einer Zwischenebene (trunk, tags, branches)
in allen Teilrepositories, so wie Sie es seinerzeit fuer das avanti-
Projekt eingerichtet haben: Erst wenn die Repositories Raum fuer mehr
als die eine, offizielle, jederzeit einsatzfaehige bzw. geradlinig
aufs naechste Release zusteuernde, Version ("trunk") lassen, koennen
mehrere an der Entwicklung beteiligte das Source-Control-System als
Werkzeug zur Kommunikation untereinander nutzen, indem sie die
Arbeit anderer betrachten und ausprobieren koennen, *bevor* sie zur
einen, offiziellen etc. Version wird.


> Gerne würden wir eine bessere Integration von C und C++ hingekriegt
> haben. Immerhin ist es gelungen, daß die Index-Kernmodule ai*.c
> und ai*.cpp identisch sind.

.h-Header-Dateien koennen wohl als fuer beide Syntaxen formuliert werden,
und wenn eine .a-Library herauskommt, duerfte es doch egal sein, weil
erst der Linker alles zusammenfuegt?

Wg. stricmp und Konsorten oder auch hoeher gelagerten Problemen (avanti
etwa wuerde Komplexitaet und Ressourcenverbrauch verlieren, wenn das
Linux-typische gemeinsame select() fuer Sockets und "echte" Dateihandles
eingesetzt werden duerfe, darf das wg. Win32 aber nicht): Allegro als
OpenSource kann sich viel hemmungsloser als frueher an anderen Open-Source-
Projekten bedienen, und man sollte mittelfristig einmal auf die Suche
gehen, ob es plattformuebergreifende, "abstrahierende" Libraries gibt (boost?),
deren Einsatz moeglichst viele Windows/U**X-Fallunterscheidungen in den
eigentlichen allegro-Modulen ueberfluessig macht.


viele Gruesse
Thomas Berger