[Allegro] OpenSouce, momentan in Arbeit: a99

[Bernhard Eversberg]

Am 12.04.2012 13:05, schrieb Thomas Berger:
>
> 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)
Die realisieren jeweils zusammen eine Library. Die ac15-Dateien stellen
Klassen dar, das ist richtig, aindex dagegen nur eine
Funktionsbibliothek. Daraus bedient sich die Klasse INDEX des
ac15-Pakets, die wiederum ein Abkömmling der Klasse EXET
(Exportparameter) ist.

> ... 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:
NUR die aindex-Dateien sind vollredundant! *Das* hinzukriegen war
schwer. ac15 ist keineswegs identisch, vielmehr nur funktional,
aber in C statt C++ formuliert. Die C++-Klassen entstanden 1997,
die C-Dateien ab 1985.
Der Grund für die Duplizität ist nur, daß der C-Compiler nicht .cpp
uebersetzt und der C++-Compiler nicht .c - oder wir das nicht
hingekriegt haben.

> Spaetestens die dritte Fehlerkorrektur wird nur
> in einer der beiden Baeume durchgefuehrt werden, weil zwischendurch
> das Telefon geklingelt hat...
>
Sie sind unverbesserlich. Korrekturen in diesen Dateien sind so selten,
daß das nicht vorkommt. Ehrenwort. Gerade jetzt gab es noch die
Korrektur wegen Fischers Problem, aber nur in der C-Datei exet.c, nicht
in dem (nicht austauschbaren) Pendant exet.cpp

> 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),
Leider gar nicht egal, wie wir leider feststellen mußten - oder
irgendwas nicht hingekriegt haben. Also vergessen Sie das.

>
> Die Probleme/Loesungsansaetze im einzelnen:
>
> * Doppelter Code fuer dasselbe geht m.E. allerhoechstens
> uebergangsweise, man benoetigt zumindest einen Plan, wie man den
> mittelfristig loswird
>
Sehr einverstanden, nur, wie gesagt ...
Wenn Sie das schaffen, bravo.

> * 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.
Nach langen Jahren der Arbeit mit diesen Dateien können wir diese
im Grundsatz richtigen Bedenken zerstreuen. *Da* liegen die wirklichen
Probleme nicht.

>
> * *Header*-Dateien lassen sich so formulieren, dass sie sowohl fuer
> ANSI-C als auch fuer C++ nutzbar sind.
Gut, das gehört zu den Dingen, die Sie dann wohl besser hinkriegen
können als es uns gelungen ist.
Bedenken Sie, daß Sie jetzt das Produkt einer sehr gründlichen
Überarbeitung vor sich sehen, und seien Sie froh, die Dateien nicht
vor einem Jahr gesehen zu haben. Das Ganze kann man nur schrittweise
weiter verbessern, nicht in einem Rundumschlag.  Sie blicken aber
auch jetzt noch teilweise tief hinab in die Geschichte der C-Codierung,
deren Praxis noch in den 80ern aus heutiger Sicht schauerlich war. Es
war wirklich ein Kraftakt sondergleichen, alles - z.T. vorher 20 Jahre
nicht angefaßt - erst einmal in den jetzigen Zustand zu überführen, der
zugegebenermaßen noch immer sehr suboptimal ist. Zigtausend Zeilen.
Es gibt in ac15 z.B. horrend viele globale Variablen, zudem
intransparent benannt, für Objektierer wie Javaner der Horror, die sind
aber alle in allegro.hpp zusammengefaßt und kommentiert, zu dem es in
der C-Welt noch kein Pendant gab, in den ac15-C-Programmen also leider
auch noch nicht! Aber wie gesagt, da brauchen Sie im atools-Paket nicht
dran rühren.

>
> * C++ kennt "extern C" (das Betriebsystem, also GNULib oder MFC,
> stellt sich dem Programm ja auch nicht unbedingt rein
> klassenorientiert da)
>
Ich weiß nicht, ob das weiterhilft.

> * *Headerdateien* "darf" man m.E. in andere Projekte kopieren
> (Versionierung empfiehlt sich)
>
ist "darf" in rechtlicher Hinsicht gemeint? Aber wieso wäre das hier 
relevant?

> * "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).
Klar, alles sehr elegant, aber das sind neue Konzepte, die zur Zeit der
Entwicklung noch nicht existierten, daher also im Kern der Quellen
sich nicht niederschlagen konnten.

>
> * Unter Linux geht dieses "Installieren" auch fuer statische
> Libraries (libsoundso.a), ob es dafuer in der Microsoft-Welt ein
> Pendant gibt, weiss ich nicht.
>
Ich auch 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)
>
Also nehmen Die die ai- und ac15-Dateien erst mal wie sie sind und
verschwenden Sie darauf einfach keinen Gedanken! Da müssen Sie bestimmt

inhaltlich nicht drangehen, oder uns, für's erste, vorher fragen.

>
> 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.
>
Ja gut, dann strukturieren Sie mal in diesem Sinne, wir übernehmen das dann.

> 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)
ja eben, wirklich nicht einfach. Sonst hätten wir die einzig gute
und richtige Lösung vielleicht schon.

> ... 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...
>
Sagen Sie, für welche Bereiche Sie welche Berechtigung brauchen, dann 
kriegen Sie die.
Oder legen Sie doch einfach einen ganz neuen Baum an und ordnen dort
alles nach Ihrem Gusto. Können Sie erst mal bei sich machen, dann
später rüberschieben.

B.E.