[Allegro] OpenSouce, momentan in Arbeit: a99

[Thomas Berger]

Lieber Herr Eversberg,

>> Ein /Verzeichnis/, das drei separaten /Repositories/ uebergeordnet
>> ist? Wie sollte das gehen?
>>
> Versteh ich nicht so richtig, aber na gut, dann ordnen Sie die Dateien
> so um, daß es geht. Ich weiß nur, daß es bei uns geht, aber wenn Sie
> eine andere Anordnung präferieren und diese dann portabler ist, dann
> stellen Sie diese Anordnung her und machen damit ein neues Repo auf.

Meine ganz grundsaetzlichen Probleme mit der Anordnung hatte ich
auch schon einmal angesprochen und inzwischen sehe ich die
Duplizitaet der fundamentalen Komponenten ("aindex" und "ac15",
die scheinen jeweils eine C++-Klasse realisieren zu wollen)
als ernstes Problem an: Die liegen ja einerseits als separate
C++-Projekte in separaten Repositories, aber bereits der Code
liegt als an Namenspraefixen unterscheidbaren C-Dateien noch
einmal vollredundant im atools-Verzeichnis: Spaetestens die
dritte Fehlerkorrektur wird nur in einer der beiden Baeume
durchgefuehrt werden, weil zwischendurch das Telefon geklingelt hat...

Bei/fuer acon werden statische .lib-Dateien fuer den Linker
produziert (und wenn das mit den eigentlichen acon-Dateien
verlinkt wird, ist ja voellig egal, ob das C oder C++-Quellen
waren), im atools-Fall hingegen wird alles auf Ebene der
einzelnen .o-Dateien zusammencompiliert, also ohne libaindex
und libac15 als Zwischenschritte.

Die Probleme/Loesungsansaetze im einzelnen:

* Doppelter Code fuer dasselbe geht m.E. allerhoechstens
  uebergangsweise, man benoetigt zumindest einen Plan, wie
  man den mittelfristig loswird

* Die Quelltextabhaengigkeiten zwischen libaindex und libac15
  halte ich fuer ein Problem, auch wenn es "nur" um Headerdateien
  geht: Zumal diese Projekte in verschiedenen Repositories liegen
  und die gegenseitigen Bezuege in Form von (immerhin nur relativen)
  Pfaden in den Makefiles stehen: Ich brauche da dann immer fuer
  das jeweilige Einzelprojekt "externes" Wissen, wie diverse
  Verzeichnisse lokal anzulegen sind, damit ich den Build-Prozess
  auch nur anstossen kann.

* *Header*-Dateien lassen sich so formulieren, dass sie sowohl
  fuer ANSI-C als auch fuer C++ nutzbar sind. Wenn es also zu
  libac15.a eine Headerdatei libac15.h gibt, die das "Interface"
  definiert, dann kann diese sowohl Klassendefinitionen fuer
  C++ als auch ein eher prozedurales Interface fuer C definieren.

* C++ kennt "extern C" (das Betriebsystem, also GNULib oder MFC,
  stellt sich dem Programm ja auch nicht unbedingt rein
  klassenorientiert da)

* *Headerdateien* "darf" man m.E. in andere Projekte kopieren
  (Versionierung empfiehlt sich)

* "Normal" sind heutzutage(?) natuerlich eher dynamische Libraries,
  die zur Laufzeit an das Binary gebunden werden, also DLL's bzw.
  .so-Dateien, die kann man dann auch separat im System installieren
  (in Linux-Distributionen oft zweigeteilt: Das eigentliche Paket,
  das die binaeren Libraries installiet, dazu ein "devel"-Paket, das
  die Headerdateien installiert, so dass man dann auch eigenes "gegen"
  diese Libraries compilieren kann, Kopieren von Headerdateien entfaellt
  dann).

* Unter Linux geht dieses "Installieren" auch fuer statische Libraries
  (libsoundso.a), ob es dafuer in der Microsoft-Welt ein Pendant gibt,
  weiss ich nicht.

Es gibt nun sehr viele Loesungsansaetze und mein Wissen um den
Aufbau von Visual C++-Projektdateien ist sehr beschraenkt und das
von VisualStudio 6-Projekten ist absolut Null:

acon, a99, atools koennten voraussetzen, dass ein hypothetisches "liballegroc"
(oder liba99, libac15) bereits (also Objekt oder aus Sourcen gebaut)
vorhanden und "installiert" ist, dann werden nur die zugehoerigen
Header-Dateien benoetigt, und die sind entweder bei acon etc. dupliziert
oder ebenfalls installiert (hat Win32 ein systemweites Pendant zu /usr/include
oder gibt es einen interaktiven Konfigurator, der einer ausgelieferten
Projektdatei reale Pfade hinzufuegen kann)

Oder im SVN koennen auch noch "Projektverzeichnisse" angelegt werden, die
die relevanten Dateien fuer diverse Buildsysteme enthalten, die Sourcen
laegen dann konsequent in Unterverzeichnissen und es gaebe entweder
Readmes ("libac15.a bauen oder besorgen und dort hinlegen") oder per
svn:include dort direkt einbinden.

Ich hatte allerdings auch schon einmal angesprochen, dass "Name des Projekts",
Lizenzdateien, Versionsnummern typischerweise in den uebergeordneten Build-
Dateien hinterlegt werden und man wirklich darueber nachdenken muss, ob
libac15 oder libaindex "Komponenten" mit eigener Versionierung sind denn
sonst kommt beim Compilieren von acon Version x u.u. jedes Mal etwas anderes
heraus, je nachdem welche Momentaufnahmen von libaindex und libac15 ich
erwischt habe.

Fast orthogonal dazu sind die Fragen nach guenstiger Organisation des oder der
SVN-Repositories. Dazu gehoeren nicht nur die Fragen der trunk/branches/tags
Zwischenebene (und es ist wirklich keine einfache Entscheidung, ob
allegro/{branches,tags,trunk}/.../{ac15,aindex,...} oder
allegro/{ac15,aindex,...}/.../{branches,tags,trunk}
eine angemessene Organisationsform ist) sondern auch die Entscheidung, mehrere
*Repositories* (statt mehrere Projekte in einem Repository) zu eroeffnen, die
ich bis vor kurzem aus eher theoretischen Erwaegungen fuer Overkill gehalten
haben, die mir aber inzwischen ganz Praktisch Probleme bereitet: Sie hatten mir
neulich fuer eines dieser vielen Repositories eine Nutzerkennung spendiert (wg.
Schreibrechten), da ich aber etwa fuer acon mich aus mehreren Repositories
bedienen muss, die diese neue Kennung gar nicht /kennen/ bekomme ich mit
gaengigen SVN-Clients dabei arge Probleme: Denn ich benutze ja den HTTPS-
Transportmechanismus, und Ihr Server fragt stets nach Authentisierung fuer
"https://svn.allegro-c.de:443", egal welches Repository ich nutze. Insofern
wird auch nur ein Passwort bei mir gecached und will ich dorthin
zurueckschreiben, wo ich es darf, kann ich anschliessend die anderen Bereiche
nicht mehr lesen...

viele Gruesse
Thomas Berger