eibd(war bcusdk) Fork -> knxd

[makki]

Also, meine Tests mit cmake (es geht - inkl. pthsem!) waren nicht gerade erfrischend.. Um nicht zu sagen: ziemlich ernüchternd.
Es geht - auf genau einem System. OpenWRT, Openembedded (von MingW oder OSX garnicht zu sprechen..) waren ein Griff ins Klo.

Vielleicht ist alt doch nicht unbedingt schlecht? Denn ich hätte gerne, das es weiterhin auf allen Plattformen läuft..

Makki

[makki]

Die Anpassung an ein anderes OS macht m.E. aber erst Sinn, wenn wir einen einigermassen stabilen Kern des neuen knxd haben, ich meine damit: nach dem Refactoring und Umbau in ein neues Buildsystem.

Sehe ich genauso - und: sehr schön schon drei dafür zu haben!
Spricht etwas gegen cmake auf OS/X ?

Ich favorisiere auch cmake, vielleicht weil ich die auto*-Freakshow zu gut kenne

Makki

[mjoe]

OSX kann ich gerne beisteuern, ist seit ca. 10 Jahren meine primary Plattform. Die Anpassung an ein anderes OS macht m.E. aber erst Sinn, wenn wir einen einigermassen stabilen Kern des neuen knxd haben, ich meine damit: nach dem Refactoring und Umbau in ein neues Buildsystem.

[Jockel]

Natürlich sollte das kein Problem sein, weil so unterschiedlich ist *nix im Kern nicht von NEXTstep/OS/X.

Deswegen nutze ich OSX, unter Linux hab ich keinen Desktop gefunden der mir wirklich zusagt und so hab ich das Beste aus beide Welten

Mit Zusagen bin ich immer etwas virsichtig, da es bei mir zeitlich immer mal wieder knapp werden kann. Aber ich bin gerne bereit die Entwicklung unter OSX zu unterstützen!

Den Build Mechanismus der macports muss ich mir mal anschauen, bislang hab ich die nur benutzt. Schöner wäre natürlich den knxd auch ohne übersetzen zu können, je nach benötigten Bibliotheken könnte das sber aufwendig werden.

[MarcusF]

Es gibt bereits einen eibd-Port für Mac OS X auf macports, der leider keinen Maintainer mehr hat.

[makki]

Jockel,

dann wärst du ja prädestiniert als Maintainer für OS/X!
Genau das suche ich (auch wenn ich keinen Mac anfasse, muss das kein tiefer Hass sein ))
-> Leute die sich um "ihre" Plattform kümmern.

Natürlich sollte das kein Problem sein, weil so unterschiedlich ist *nix im Kern nicht von NEXTstep/OS/X..
Vor allem da der eibd schon immer auf Portabilität ausgerichtet war, und bleiben soll! Sowie keine externen Abhängigkeiten mitbringt.

Makki

[Jockel]

(von BSD, MingW oder OSX hab ich übrigens keine Ahnung..)

Den Eid unter OSX fänd ich schon nett, ev. lohnt da ein Blick auf die einschlägigen Paketmanager wie macports (nutze ich) oder homebrew.

Häufig ist es kein (großes) Problem SW für Linux unter OSX zu übersetzen, das kann ich gerne testen!

[makki]

Wie wäre es mit einer Definition und Aufteilung der einzelnen Aufgaben an verschiedene Personen? Dann macht jeder für seinen Bereich einen Plan, stellt ihn vor und bei Zustimmung geht es dann an die Umsetzung.

Das klingt nach einem sehr guten Ansatz!
Eine ML kann ich auch jederzeit einrichten, falls einem das Forum nicht passt, ebenso gibt es die Zusage vom knxu-Forum für ein Unterforum.
Bis dahin tuts IMHO dieser Thread.

Aufgaben (die ich sehe):
- Build-System
- Packages (= mehrere Aufgaben)
- vorhandene Patches aus der ML, meinem Fundus, "eibd-hard" (das sind ein paar Sachen schlecht, aber nicht alles!)
- Zukünftige Features abstimmen.

Ich wiederhole das gerne & oft: Ziel ist eibd->knxd - keine Einzelaktion im stillen Kämmerlein.
Genau deswegen habe ich diesen Thread gestartet, um möglichst viel Input & Feedback zu erhalten.

bcusdk/eibd wurden von Martin Koegler im Kern IMHO sehr, sehr gut aufgebaut!
Ich möchte das nicht "abreissen" sondern nutzen - aber natürlich muss man im Vorfeld auch extreme Änderungen wie das Build-System, Repository etc. in Betracht ziehen.
(Über C++ diskutieren wir bitte nicht, höchstens über die API's )

Maximale "Bewegungsfreiheit" in grundlegenden Fragen haben wir aber nur jetzt zum Start.

Ich definiere mal meine "Wünsche":
- Standalone (ohne bcusdk, pth[sem])
- 100% Abwärtskompatibel
- brauchbar auf vorhandenen, "alten" Plattformen; d.h. keine Verwendung von "latest&greatest", sondern etablierte, verbreitete Sachen.
Präventiv: Hierbei geht es NICHT um WG! Sondern um alle Plattformen, die nunmal ein paar Jahre hinter "latest&greatest" auf Stand sind..
Ich habe schon viel zu oft - bei vielen Projekten - mich wegen einem unnötigen "Feature" in *make* herumgeschlagen, nur weil der Entwickler nur auf seinem System zugange war..

Ich versuche mich gerade testweise mit cmake

Makki

[ctr]

Wie wäre es mit einer Definition und Aufteilung der einzelnen Aufgaben an verschiedene Personen? Dann macht jeder für seinen Bereich einen Plan, stellt ihn vor und bei Zustimmung geht es dann an die Umsetzung.

[mjoe]

Es geht immernoch rein um bcusdk(eibd)->knxd.
Ich hatte es mir einfacher vorgestellt

Der Hund liegt immer im Detail begraben. Ich würde schrittweise vorgehen, bei zuvielen Variablen verliert man schnell den Überblick. Vor allem musst Du/wir uns die Frage stellen was genau das Ziel sein soll, was soll alles abgedeckt werden, wo wollen wir hin.

Bei einem Wechsel des Buildsystems kommt man meistens nicht darum herum, den Code zuerst auf das Minimum zu reduzieren, resp. zu entschlacken, und ihn erst danach erneut, sozusagen von Grund auf in das Alternative Buildsystem zu integrieren.

Btw. hier gibts einen Überblick dazu http://www.scons.org/wiki/SconsVsOtherBuildTools

[DerSeppel]

Also ich bin momentan voll im Bau-Stress. Aber wenn sich der Staub ein wenig gelegt hat, pack ich mit an.
Habe mal einen GitHub-Account angelegt und den Code ausgecheckt. Zum drüber schauen.

Git finde ich prinzipiell die richtige Lösung. Bin zwar nicht soo der Fan von Klicki-Bunti Clients, aber wir haben für Teilprojekte gerade git mit "SourceTree" als Client in der Firma eingeführt. Ist eigentlich ganz nett und sollte auch mit kostenloser Lizenz zu haben sein.

Ansonsten wäre CMAKE meine Wahl. Setzen wir auf der Arbeit für fast alle Projekte ein. Ich kann auch zwischenzeitlich mal schauen ob ich bei der Konfiguration unterstützen kann.

[makki]

cmake

Na, da wäre ich ja bei dir, aber wie ersetze ich damit autoconf/make, Doku, Auto-API usw.
Das ist keine ketzerische Frage, sondern eine sachliche.. Es ist mir bisher nicht wirklich gelungen - mit all den Abhängigkeiten der diversen Pakete etc..

Es geht immernoch rein um bcusdk(eibd)->knxd.
Ich hatte es mir einfacher vorgestellt

Makki

[Robert]

cmake

[makki]

Ich hadere gerade etwas, daher eine Frage (eher Entwickler, weniger Anwender - inkl. meiner subjektiven Antworten):
Was findet ihr besser:

- autoconfig/automake oder cmake
- Doku-System (so lassen oder was "besseres")

+ den ganzen Rest davon: was ihr machen könnt, ist mich mit Vorschlägen&Input zu versorgen..

Makki

(ich nenne bewusst keine Alternativen, um die AW nicht zu beeinflussen..)

[makki]

Danke für die Antworten und werde gerne darauf zurückkommen; ich kämpfe noch etwas mit den "Basics"
Die muss ich aber erstmal selbst lösen.
Also Build-System, möglichst integrierte Doku und der "automagic" Client-API, automatisierte Tests, ... habe das offen gestanden etwas unterschätzt bzw. letzte Woche zuwenig Zeit gehabt.
Für einen ersten commit ist da noch zuviel Mist drin, es macht ja keinen Sinn bereits bekannte Probleme zu diskutieren..
(ich teste vorerst mit einem lokalen GIT..)

Ohne gescheites Build-System machts aber IMHO auch wenig Sinn, denn genau das würde ich anstreben, das es von Debian (z.B. WG oder RPi) über OpenEmbedded, OpenWRT bis Synology (von BSD, MingW oder OSX hab ich übrigens keine Ahnung..) z.B. Paketbetreuer/Tester gibt und dies dann auch soweit irgend möglich "Upstream" auch automatisiert stattfinden kann.
Möglichst kein "zusammenfummeln" für eine spezifische Plattform mit nachträglichen, lokalen Patches. (der geneigte Leser weiss evtl., was ich meine.. der eibd & das Packaging z.B. auf dem WG ist letztlich seit Jahren "händisch gepatched"; das ist einigermaßen ineffizient..)

-> Ich habe den eibd und pthsem selbst schon auf so viele Plattformen "gefummelt", das mir sehr wichtig ist, hier zukünftig - soweit möglich - ohne manuelle Eingriffe bei jedem Release auszukommen..
Auch s.o.: Thema pthsem. Weil so genial das ist, ebensoviel Kopfweh bereitet das z.B. bei der Paketerstellung für andere Plattformen..


@Herbert: Die CoDeSys-Frage verstehe ich in diesem Kontext nicht wirklich?
Entweder per vorhandener, gut dokumentierter API (die auf jeden Fall abwärts-kompatibel bleiben wird!) oder per eben via KNX.
Dafür brauchen wir keinen Fork (?)


@ChrisM: nun wir hatten ja im Vorfeld (PN/eMail) schon darüber gesprochen und du hast freundlicherweise zugestimmt, das unter OA "einzuhängen";
letztlich haben mich aber erstmal die Vorteile von GitHub überzeugt, das jeder ohne "Voranmeldung" mitmachen kann.

Ich strebe hier absolut nicht den "Project-Lead" an, ganz im Gegenteil. Nur die Initiative..


@Hendrik: zur Kommunikation tuts bis zu einem Release 0.0.6 / 1.0 (s.o.) denke ich erstmal das Forum, da es bis dahin nur um die Basics im selben Funktionsumfang geht.
Danach kann man denke ich mal sehen und abstimmen, was da Sinn macht; Unterforum (denke ich eher weniger), GitHub (bietet einiges- von Wiki bis ML) oder ein Umzug zu Openautomation/SF.

Makki