Ankündigung

Einklappen

Hinweis

Die Forenregeln wurden überarbeitet (Stand 7.11.22). Sie sind ab sofort verbindlich. Wir bitten um Beachtung.
Mehr anzeigen
Weniger anzeigen

eibd(war bcusdk) Fork -> knxd

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    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.

    Kommentar


      #17
      Zitat von ctr Beitrag anzeigen
      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
      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
      -> Bitte KEINE PNs!

      Kommentar


        #18
        (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!

        Kommentar


          #19
          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
          EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
          -> Bitte KEINE PNs!

          Kommentar


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

            Kommentar


              #21
              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.

              Kommentar


                #22
                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.

                Kommentar


                  #23
                  Zitat von mjoe Beitrag anzeigen
                  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
                  EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                  -> Bitte KEINE PNs!

                  Kommentar


                    #24
                    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
                    EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
                    -> Bitte KEINE PNs!

                    Kommentar


                      #25
                      Zitat von makki Beitrag anzeigen
                      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
                      Der klassische Weg ist sicher nicht falsch. Ich hätte daran auch vorerst nichts verändert und den Fokus auf die anderen Teile gelegt. Automake und co. sind halt doch recht verbreitet und gut etabliert. Von mir aus, bleib dabei ..

                      Kommentar


                        #26
                        Um wie viele Zeilen Code geht es hier denn? (hab gerade keinen Sourcen zur Hand)

                        Ich halte ein komplettes Redo immer für die bessere Alternative. Man überlegt sich halt erstmal was die bestehenden Probleme sind und wo man hin möchte.

                        Legt dann fest wie man das programmieren möchte, und arbeitet das dann ab.

                        Dann hat man nicht das Problem das man immer versucht Abhängigkeiten zu lösen, sondern kann vorher schon selbst bestimmen welche man überhaupt haben möchte.
                        Nils

                        aktuelle Bausteine:
                        BusAufsicht - ServiceCheck - Pushover - HS-Insight

                        Kommentar


                          #27
                          Um noch die Frage von Makki zu beantworten, cmake ist auf dem Mac von Haus aus nicht installiert. Es gibt es natürlich, aber das erhöht wieder die Abhängigkeiten. Automake & Co sind auch nicht meine größten Freunde, aber gewisse Vorteile sehe ich da schon.

                          Kommentar


                            #28
                            Zitat von makki Beitrag anzeigen
                            Präambel

                            Aber Doku ist nicht meine Stärke, ebensowenig (automatisierte?) Tests und mit GIT bin ich komplett "blank".
                            Bei der Doku kann ich unterstützen.
                            Stellt sich natürlich die grundlegende Frage nach dem wie dokumentieren wir?
                            Ist ein Wiki immer noch die präferierte Art und Weise der Dokumentation?

                            Viele Grüße
                            Jörg

                            Kommentar


                              #29
                              Zitat von gregory1969 Beitrag anzeigen
                              Stellt sich natürlich die grundlegende Frage nach dem wie dokumentieren wir?
                              Markdown als Textdatei hat den Vorteil, dass man es auf der Kommandozeile lesen kann und es auf zB GitHub automagisch schoen angezeigt wird. Und die Doku zieht man dann immer zusammen mit dem Code runter, man hat sie also immer auf den Maschinen wo knxd laeuft...

                              Wenn ihr soweit seid, dass knxd unter Debian sauber baut meldet euch per PM; packaging & upload kann ich machen. Email per PM extra freigeschaltet da ich sonst nicht oft hier bin.


                              Richard

                              Kommentar


                                #30
                                Vorschlag oder Hinweis...

                                Die Jungs von Wiregate setzten auch den EIBd ein. Vielleicht haben die ja interesse sich an dem Projekt zu beteiligen.

                                Gruß
                                Frank
                                Mein Bus; 2 Linien bestehend aus Gira USB Schnitstelle, B&J Linienkoppler, 3* Gira Dali GW, 6*B&J Dimmaktoren (4K), 4*B&J Jalousienaktor (26K), 1*MDT Schaltaktor (20K), 2*B&J Ventilantriebsaktoren (18K), 8*B&J Binäreingang (66K), 6 Gira Präsenzmelder, 5*B&J RTR, 22*B&J Tastsensoren, Wiregate und Gira Homeserver

                                Kommentar

                                Lädt...
                                X