[Allegro] Fragen zur SVN Struktur für acon

[Thomas Berger]

Lieber Herr Eversberg, lieber Herr Lackhoff,

>>    https://svn.allegro-c.de/svn/atools/
> 
> SVN-technisch funktioniert es einwandfrei, kompilieren habe ich nicht
> versucht. Mir ist nur aufgefallen, dass es ein paar Dateien und das
> Verzeichnis .deps nicht mehr gibt. War das eine gezielte Aufraeumaktion
> oder fehlt vielleicht noch etwas?
> 
> Wie gesagt wuerde ich eher eine Verzeichnisstrukur dieser Art vorschlagen:
> 
> [allegro]/trunk/atools
> oder
> [allegro]/atools/trunk/src
> oder, wenn es auf Dauer bei Einzelrepositories bleiben soll:
> [atools]/trunk/src
> Daneben natuerlich jeweils tags und bei Bedarf branches.
> 
> Weil bei SVN alle Aktionen erst einmal verzeichnisorientiert sind,
> braucht man an einigen Stellen ein Unterverzeichnis, wobei
> zugegebenermassen auch "trunk" dafuer genutzt werden kann. Da das aber
> eigentlich fuer das root-Verzeichnis steht, finde ich eine der o.g.
> Strukturen sauberer.
> 
> Auf jeden Fall ist die erreichte Struktur schon mal ein klarer Fortschritt!

Absolut.

Zur Binnenstrukturierung eines solchen Projekts kann ich im C/C++-Universum
wenig sagen, ich hatte allerdings letzte Wochen schon angeregt, die ai*.c/.h
in ein Unterverzeichnis mit eigenen Makefiles auszulagern: die scheinen
ja eine in sich geschlossene Funktinalitaet zu realisieren, muessten also
eigentlich ein Bibliotheksmodul libai.a ausspucken, das dann in die attols
eingelinkt wird (uebergangsweise, denn im c++-Zweig gibt es ja eine Dopplung
als eigenes Projekt aindex).

Zur "src"-Anregung von Herrn Lackhoff kann ich sagen, dass ich aus der
Perl-Welt das ebenfalls so kenne: Selbst die Haupt-Quellen sind in
Unterverzeichnissen, auf der obersten Ebene befinden sich eigentlich
nur Makefiles. Dort geht das sogar so weit, dass die Resultate in einem
eigenen, parallelen Verzeichnisbaum entstehen, der Sourcen-Baum also
gar nicht angetastet wird. Mit "normalen" make's ist das allerdings
schwer erreichbar, hier wird ganz stark die Tradition unterstuetzt,
dass nicht nach "Stationen" unterschieden wird, sondern nach Zusammenhaengen
und daher *.o und *.exe im gleichen Verzeichnis enstehen, wo auch die
Quellen liegen. (Das widerspricht allerdings nicht dem Ansatz "Quellen in
Unterverzeichnisse", sondern nur dem "Binaries in separate Verzeichnisse").

Mit Unterverzeichnissen bietet es sich an, auch noch ein Unterverzeichnisbaum
fuer Tests aufzubauen, die in Folge eines "make test" dann automatisiert
durchlaufen werden koennen. Obwohl sich kommandozeilen-Tools wie aconoder
die atools gut zur Automatisierung eignen, ist es mit automatisierten
Tests so eine Sache: Die Tools bringen eine recht komplexe Operation vom
Anfang bis zum Ende, man muesste unzaehlige Testdatenbanken in das
Projekt einbringen mit Ausgangsdaten und hinterlegten, "korrekten" Ergebnissen
(aber was ist ein "korrekter" Index: soll der byteweise verglichen werden?),
das ist Overkill. Im Rahmen eines "make test" muessten Dinge kontrolliert
werden und auffallen, wie das letzte Woche von Ihnen bemerkte Regression bei
der Endianness unter Solaris. D.h. alle Einzelfunktionen der aindex-
Bibliothek und diverse andere Einzelfunktionen muessten separat getestet
werden. Das "osd"-Demoprogramm koennte vielleicht zu einer Testsuite
fuer die Einzelfunktionen ausgebaut werden, waere dann allerdings immer
noch kein Test fuer srch, index, import. Eventuell kann man den Modulen
einen Schalter fuer wirklich paranoides Loggen spendieren, so dass bei
einer Beispielindexierung etc. unglaublich viele standardisierte
Informationen zu vorher/nachher diverser Einzelschritte anfallen, die
dann maschinell im Rahmen eines "make test" ausgewertet werden koennen
(gerade bei "import" kann man ja gut vorher und nachher vergleichen, etwa
wenn man Zoo absurd reduzierter Importparameter auf winzige Schnipsel
von Ausgangsdaten loslaesst: Ich glaube Herr Eger kann hier einiges
beisteuern). Oder aber (so scheint es "configure" zu machen), es werden im
Rahmen der Tests hunderte standardisierter Mini-Programme kompiliert, die unter
Rueckgriff auf die Bibliotheksfunktionen jeweils einen Mini-Aspekt des
komplexen Ablaufs nachtraeglich ueberpruefen (empfiehlt sich als
Test fuer "index"?).

viele Gruesse
Thomas Berger