[Allegro] SVN und Make, Test und Demo mit osdp

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Gut, besseres Wissen haben Sie wieder mal überzeugend demonstriert,
> und daß es uns daran und überhaupt am Durchblick mangelt. Wir arbeiten
> dran, sobald wir dazu kommen.
> 
> Jetzt könnte das bessere Machen folgen. Sie haben Schreibrecht, auch
> für osdp. Nun zeigen Sie uns und der Community, was ne Harke ist. Oder
> wie geht eigentlich OpenSource? (Hatte das eigentlich schon mal
> angeregt, erneuere aber gern die Ermunterung dazu.)

Das ist derzeit nicht hilfreich: Was nutzt mir der Fuehrerschein,
wenn das Auto in einer engen Garage quer zum Tor zusammengebaut wurde?


> Aber ok, morgen ist schon Expertentreff, da bleibt soviel Zeit nicht.
> Oder Sie präsentieren da mit CMake o.a. was Bessres, dann ist Schluß
> mit dem Schlamassel und allen geholfen.

Ja, sicher habe ich das vor. Aber nicht im Sinne von "was besseres
praesentieren", sondern als Diskussionsgrundlage dafuer, wie "Dinge"
wie Projektdateien und Verzeichnisstruktur organisiert werden
koennten.



> Um auf jeden Fall was zu haben, was denn doch klappt:
> Ihrem Rat folgend, avanti als Beispiel zu studieren, braucht etwas
> viel Zeit.  Kollege Oberfell sandte vor einer Weile eine ganz gute
> Zusammenfassung wichtiger Schritte:
> 
> http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2012-March/035165.html
> Und dann war da noch diese Handreichung:
> 
> http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2012-January/034765.html
> fußend auf
>   http://www.lugod.org/presentations/autotools/presentation/autotools.pdf
> 
> Dies dann schnell mal eben durchspielend für osdp, mit diesem
> Dateienbestand im Ordner osdp: (die daneben noch bereitgestellten
> sind hinfällig bzw. nur für Windows-VC)
> 
>     Makefile.am
>     osdp.cpp
>     uif0ger       (nur zum Testen)
> 
> und parallel liegenden ac15 und aindex, dort bereits die libraries
> libac15.a bzw. libaindex.a, ergibt dann folgende Sequenz:
> (Reinschauen in die jeweils entstehenden -->Dateien, man sieht
> dann schon worum's geht)
> 
> autoscan
>   --> configure.scan
> 
> mv configure.scan configure.ac
> 
> autoheader
>   --> autom4te.cache
>       config.h.in
> 
> vim configure.ac
>     Ergaenzung direkt nach AC_INIT:
>       AM_INIT_AUTOMAKE
>     Ergaenzung unter # Checks for programs
>       AC_PROG_RANLIB
> 
> aclocal
>   --> aclocal.m4
>       und Aenderungen an configure.ac
> 
>   Dateien NEWS, README, AUTHORS, COPYING und ChangeLog bereitstellen,
>   Inhalt egal, sonst Fehlermeldung bei:
> 
> automake --add-missing --copy
>   --> INSTALL
> 
> autoconf
>   --> configure
> 
> automake
>   --> Makefile.in

So: Hier ist dann etwas entstanden, das - nach Bereinigung von
Zwischenergebnissen - gemaess Autotools-Philosophie zu einer
Bereitstellung gehoert: Damit laesst sich das dann (theoretisch)
auf beliebigen Systemen mit GNU/GCC-Toolchain compilieren, ohne
dass auf dem Zielsystem die diversen Autotools-Pakete vorhanden
sein muessten.


> ./configure
>   --> config.status
>   --> config.log
>   --> config.h
>   --> stamp-h1
>   --> Makefile
> 
> Das letzte ist es, was wir die ganze Zeit wollen.
> 
>   Nun in Makefile (warum, führt jetzt zu weit) die Zeile
> INCLUDES = -I$(top_srcdir)/ac15 -I$(top_srcdir)/aindex
>   ersetzen durch
> INCLUDES = -I../ac15 -I../aindex

Nun, das "warum" ist klar und ueberhaupt der Knackpunkt:
Man kann nicht drei (angeblich) unabhaengige Projekte
zu einem uebergeordneten /Projekt/ zusammenfassen, ohne
die /uebegeordnete/ Projektstruktur dafuer. Das betrifft
nicht nur die GNU-Toolchain sondern nach meinen Erfahrungen
auch CMake und MSVC (und mein naiver Menschenverstand kann
sich ohnehin nicht vorstellen, wie es ohne gehen sollte).

Aber um alle dieses in Ruhe durchzudiskutieren treffen wir
uns ja diese Woche.

viele Gruesse
Thomas Berger