Multiplattform / OpenSource

[Raspberry]

Habe das Rad-Studio probiert...
Hatte leider nur eine Demo Lizenz obwohl es anders beschrieben war. (Also abgelaufen)
Alles andere ist mir im Augenblick zu teuer.

[Paulli]

[...]
Wenn jemand sich die Arbeit macht und eine Plattform bereitstellt, wo das Programm gemeinsam entwickelt werden kann (+Versionskontrolle), dann stelle ich den Quellcode zur Verfügung.

Die gängigste Plattform dafür ist GitHub. Sowohl Synchronisation als auch Versionskontrolle ist dort kein Problem. Wenn man ein Projekt entsprechend einstellt kann jeder ganz einfach Code-Vorschläge machen, die man dann mit wenigen Klicks einbinden kann. Die Sichtbarkeit von solchen Repositories kann man nach belieben einstellen, falls der Quellcode nur mit bestimmten Personen geteilt werden soll.
Hier sind ein paar Beispiele:
https://github.com/microsoft/vscode
https://github.com/android/android-test

Ich kann so ein Repository erstellen, dafür brauche ich dann den Quellcode.

MfG
Paulli

[Erek Starwind]

Hallo Raspberry,

vielen Dank für deine Offenheit und die Bereitschaft, den Quellcode zur Verfügung zu stellen. Ich würde gerne dabei helfen, das Projekt gemeinsam weiterzuentwickeln und multiplattformfähig zu machen.

Ich habe folgende Ideen / Maßnahmen wie sich das technisch umsetzen lässt:

1. Einrichtung eines GitHub-Repositories (wie auch schon Pauli erwähnte)

Zweck:
GitHub ist die bekannteste Plattform für Versionskontrolle und Zusammenarbeit. Sie bietet:
- transparente Nachverfolgbarkeit aller Änderungen,
- einfache Möglichkeit zur Zusammenarbeit über Pull Requests,
- Verwaltung von Aufgaben und Ideen über „Issues“.
- Zugriffsbeschränkung oder öffentliche Sichtbarkeit je nach Wunsch

Ich könnte das Repository einrichten (öffentlich oder privat nach Wunsch) und dich als Hauptautor eintragen, wenn nicht schon geschehen.

2. Verwendung von CMake als Build-System (für Windows, Linux & macOS)

Zweck:
CMake ist ein modernes, flexibles und plattformunabhängiges Build-System. Ziel ist es:
- den gesamten Build-Prozess (auch unter Windows) über CMake zu steuern,
- Kompatibilität zu Visual Studio, VSCode, GCC, Clang, Ninja usw. herzustellen,
- nur noch ein zentrales Build-Skript zu pflegen – für alle Plattformen identisch.

Das vereinfacht die Wartung enorm und erleichtert neue Plattform-Ports.

3. Nutzung von Visual Studio Code (VSCode) als zentrale Entwicklungsumgebung

Zweck:
VSCode ist leichtgewichtig, frei verfügbar und ideal für plattformübergreifende C++-Projekte. Mit dem CMake Tools-Plugin wird die Integration besonders komfortabel. Vorteile:

- einheitliche Entwicklungsumgebung unter Windows, Linux und macOS,
- direkte Integration von Debugger, Build-System, GitHub und Terminal,
- keine Abhängigkeit mehr von Visual Studio-Projektdatenbanken (.vcxproj).

4. Entfernung der Borland-Runtime und Migration auf Standard-C++ (so wie von dir schon angemerkt)

Zweck:
Die Borland Runtime ist nicht portabel und behindert eine moderne Entwicklung. Ich würde die Abhängigkeiten schrittweise entfernen und:

- durch Standardbibliotheken oder plattformunabhängige Alternativen ersetzen,
- ggf. OS-spezifische Abschnitte kapseln (z. B. über #ifdef _WIN32 usw.),
- so eine Grundlage schaffen, die langfristig auch Linux und macOS unterstützt.

5. Optionale Einführung von Continuous Integration (CI)

Zweck:
Mit GitHub Actions können automatische Builds für alle Plattformen eingerichtet werden. Damit lässt sich:

- sicherstellen, dass Änderungen keine Kompilierungsfehler verursachen,
- Codequalität durch Tests validieren,
- Release-Versionen automatisch erstellen.

Das ist zunächst optional, kann aber später den Workflow erheblich verbessern.