[Allegro] Fragen zur SVN Struktur für acon

[Bernhard Eversberg]

Am 09.02.2012 18:08, schrieb Thomas Berger:
>
> ... 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,
In der C++-Variante tun sie das auch, da entsteht aindex.lib bzw.
libaindex.a

> das dann in die atools eingelinkt wird (uebergangsweise,
> denn im c++-Zweig gibt es ja eine Dopplung als eigenes Projekt
> aindex).
>
Das ist kein Projekt, weil es kein eigenständiges Programm hervorbringt,
sondern nur eingebunden wird in andere, und die eigentliche
Entwicklungsphase ist lange vorbei.

Wir haben zuerst mal folgende Bereiche, die wir als Tummelfelder für
uns betrachten:

C++-Bereich:
   ./acon   :  Da liegen acon und osdp (noch nicht, aber bald)
   ./ac15   :  Klassenbibliothek, erzeugt  libac15.a
   ./aindex :  Index-Kernroutinen, erzeugt libaindex.a

C-Bereich:
   ./atools :  srch, import, index, qrix
               Die C-Varianten der ai*.c, eigentlich nur Kopien von
               ai*.cpp, liegen hier ebenfalls mit drin.

Wegen ihres Alters sind die ai-Quellen und die ac15-Klassenbibliothek
jetzt fast statisch. Da treiben wir erst mal keinen
weiteren Aufwand mit "trunk" und "tags" usw. Auch kriegen die ai*.c
kein eigenes Unterverzeichnis im C-Bereich:  Das ist eine Handvoll
Dateien, alle kenntlich am Namen mit ai vorn, die hat man an Ort und
Stelle im  Überblick, da ist es mir zu betulich, noch extra ein
Verzeichnis dafür zu machen. Die C-Programme werden insgesamt
überschaubar bleiben und keines Verzeichnisbaums bedürfen. Neues wird
da wohl gar nicht mehr hinzukommen.

Im C++-Bereich könnten parallel zu ./acon weitere Projekte angesiedelt
werden. osdp kriegt kein eigenes Verzeichnis, weil es nur eine einzige
Datei hat. a99 wäre natürlich ein Kandidat, nur ist es auf Windows
beschränkt.

In ./acon und ./atools  werden wir gelegentlich eines Releases dann
jeweils ein Tag anlegen.

Wir haben "branches" unter ./atools und ./acon gemacht, dabei bleibt's
zunächst. Wir selber bewegen da nichts, das sind Tummelfelder für andere
Entwickler. Wer da aufforsten will, mag's tun.

> 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 ...
Uns ginge das entschieden *zu* weit. Wann soll man denn noch
programmieren? Das Arbeiten mit svn kann ja richtig in Arbeit ausarten,
also zum Selbstzweck mutieren. 394 Seiten Handbuch! Wir nutzen davon,
was wirklich was bringt, nichts was nur "nice to have" ist, keine
Quisquilien. Der Umgang mit GNU kommt ja noch hinzu zu dem SVN-Aufwand
und fordert auch seinen nicht unerheblichen Lernaufwand und weitere
Aufmerksamkeit, und da blicke ich noch immer nicht so gut durch.

>
> Mit Unterverzeichnissen bietet es sich an, ...
Solche Aussagen sind noch kein Argument! Was sich anzubieten scheint,
muß besonders skeptisch geprüft werden, ob es sich vielleicht bloß
anbiedert.

> ...auch noch einen
> 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 ...
Na sehen Sie?
Aber das können Sie halten wie Sie wollen. Wir selber jedenfalls machen
für all solche Dinge keine Baumschule auf, sondern weiter wie gehabt und
bewährt. Solcherlei Tests, die man sich dafür so ausdenkt, prüfen doch
nur, was man aus Erfahrung heraus antizipiert. Tückisch sind die Dinge,
an die noch keiner denken konnte, die z.B. durch interne Neuerungen
verursacht werden. Dazu sind jeweils individuelle Tests nötig, die man
sich ad hoc ausdenken und machen muß, und das tun wir
selbstverständlich. SVN und GNU haben dabei keine Funktion.

> ... "osd"-Demoprogramm koennte vielleicht zu einer Testsuite fuer die
> Einzelfunktionen ausgebaut werden, waere dann allerdings immer noch
> kein Test fuer srch, index, import.
Betrachten Sie die getrost als abgeschlossen! Da wird kein großartiger
Testapparat mit eigenem Baum erforderlich sein. Seit 25 Jahren sind
wir da ohne ausgekommen und jetzt sind Eingriffe eh nur noch marginal.
"Einzelfunktionen" gibt es ja nun mal *sehr* viele, und noch schlimmer
sind die evtentuellen Wechsel-, Folge- und Nebenwirkungen einzelner
Funktionen, die nur eine ganz konsequente Objektorientierung, wie sie
wohl nur Java zwingend hat, halbwegs eindämmen kann.


> Eventuell kann man den Modulen
> einen Schalter fuer wirklich paranoides Loggen spendieren,
Paranoia taugt hier nicht als Paradigma. Wir wollen keinen Code, der so
durchsetzt ist von Test-Schalter-Kaskaden, daß man den Wald vor lauter
Bäumen nicht mehr sieht und sich womöglich neue Fehlerpotentiale
einhandelt.

Für uns selber gilt: Alles mit Maß und Ziel. Wir wollen
niemandes Tatendrang dämpfen, aber müssen streng realistisch für
die eigene Tätigkeit Aufwand und Effekt ins Verhältnis setzen.

B.Eversberg