[Allegro] Expertentreffen verschieben?

[Thomas Berger]

Lieber Herr Eversberg,

> Das könnten wir längst haben! Ich hatte Ihnen Schreibrecht eingeräumt,
> nicht zuletzt weil Sie dann Dateien wie z.B. Makefile und configure.in
> einbringen könnten,. so wie sie nach Ihrer Erfahrung sein sollten und
> auch bei Ihnen sofort funktionieren würden. Genau die hätten wir
> dann sofort übernommen. Unsere Erfahrung reicht, längst zugegeben,
> nicht aus, und OpenSource bedeutet ja nun auch Einbeziehen von
> Erfahrungen anderer - falls die auch mal damit rüberkommen.

Nun, "Sourcen" alleine reicht halt nicht, "Schreibrecht" auch
nicht (es ging um "acon", das auf drei verschiedene Repositories
auf Ihrem Server verteilt ist, fuer eines davon habe ich
Schreibrecht, wenn ich das einsetze, habe ich auf die anderen
beiden kein Leserecht. Ausserdem hilft das alles wenig, wenn es
- nach /meiner/ Ansicht - um ein fehlendes viertes Verzeichnis
geht...


>> Derzeit ist  es ja so, dass man eine
>> Version auscheckt, die zuletzt mit VC6 oder VC10 uebersetzt
>> wurde, und sich fuer Compilierung unter Unix stellenweise auch
>> essentielle Autotools-Konfigurationsdateien neu erzeugen muss,
>> und selbst dann geht nichts, weil die "vorletzte" Compilierung
>> fuer Solaris stattgefunden hat oder ohne Autotools.
>>
> Nein, das ist stark übertrieben, kann nur auf unglücklichen
> Einzelbeobachtungen beruhen und deshalb ohne Beleg so nicht
> akzeptiert werden. Insbes. schieben wir nichts von Solaris aus
> ins SVN. Und gerade die Makefiles z.B. hätten sich schon seit
> längerem sowieso nicht mehr ändern sollen. Da könnten wir sie
> auch aus der "commit"-Aktualisierung rausnehmen.

Als ungluecklicher Einzelbeobachter kann ich ihnen mitteilen,
dass ausser "avanti" eigentlich nichts funktioniert. D.h.
manche Pakete habe ich in manchen Umgebungen dann doch
compiliert bekommen, das bedeutet aber nicht, dass das nach
einem "svn update" ohne erneute Anpassungen oder Konflikt-
bereinigungen immer noch funktioniert oder auf einer anderen
Maschine einfach reproduzierbar waere. "Rausnehmen" hilft
da insofern, dass wir uns darueber verstaendigen muessen, was
vom Buildsystem generierte Dateien sind und was nicht.


>> D.h. nach grundlegender Klaerung von "was gehoert ins SVN",
>> "wie sind die Verzeichnisse organisiert", "welche Toolchains"
>> (ich wuerde gerne CMake und Boost vorstellen) sollten wir *sofort*
>> ausprobieren, ob die diskutierten Loesungen tragfaehig sind
>> und die daher noch vor Ort umsetzen.
>>
> Spricht ja gar nichts gegen.
> Dafür sind wir jederzeit offen, nicht nur bei einem Expertentreffen.
> Weil aber sowas auch ungeahnt mehr Zeit brauchen kann, ist es besser,
> wenn Sie es schon weitestmöglich vorbereiten. Änderungen an den
> Einstellungen und Setzungen der Makefiles usw. haben sich von uns aus
> schon länger nicht ergeben, davon können Sie mal ausgehen.

Wenn ich seit Jahren nur Cross-Plattform C/C++-Entwicklung betrieben
haette, wuesste ich wie es geht und koennte sagen, wie alles
aufzusetzen ist und warum alle abweichenden Ansaetze nach spaetestens
50 Schritten direkt ins Verderben fuehren. Dem ist aber nicht so und
hier auf der Liste ist m.W. auch niemand vertreten, der genuegend
routiniert waere um solche Vorgaben zu machen. Also bleibt uns
"Experten" nur der Weg, ein gemeinsames Verstaendnis der Probleme
zu entwickeln, und uns gemeinsam Kenntnis im Einsatz der Werkzeuge
zu erarbeiten, die andere sich fuer solche Situationen ausgedacht
haben.

viele Gruesse
Thomas Berger