Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
@Jumi: Am Releas wird gerade gearbeitet doch hängt es bei einem Freizeitprojekt immer von denen ab die ihre Freizeit darin investieren...
Ich z.B. habe alleine gestern und heute insgesammt ca. 10 Stunden in die Doku gesteckt. Das sieht keiner aber ich hoffe damit einen Beitrag für ein baldiges Releas zu leisten.
Die hier diskutieren sind doch eh "aktive", also warum gegenseitig das Leben schwer machen (lassen). Wie gesagt, wenn jeder brav seinen Kram hier irgendwo posten würde wäre das kein Thema.
Das rrdtool haben wir schon erledigt und für den eibd (incl. eibread/write) gibt es Debian x86 und armhf packages ... wo liegt denn das eigentliche Problem?
Naja, die entsprechenden Header-Dateien des bcusdk wird's immer brauchen - denn in denen ist die API für den eibd drinnen.
=> Ohne bcusdk-Paket machts keinen Sinn
Das ist aber allgemein eher unüblich würde ich behaupten, gängiger ist es gegen vorhandende Header eines anderen Pakets zu kompilieren. Die kann man entweder vorrausetzen ("bcusdk-dev"?) oder gleich "mitbringen", dann aber eben nicht das ganze Paket sondern nur die Header.
Wenn das nicht jmd anderes schon gemacht hat, werde ich die nächsten Tage mal die Machbarkeit prüfen.
Eine Mütze schlaf hat da geholfen. Aber beim Lesen steigt der Puls schon wieder. Aber ich bemühe mich ;-)
Im von ctr verlinkten Beitrag steht doch sogar wie man es kompilieren kann.
Und genau das habe ich im Nachbarthread auch empfohlen.
Nochmal:
Mir geht es darum:
Den eibd bekommt der Dau schon installiert, weil es Pakete dafür gibt.
Die CV nicht. Und da scheitert es am eibread/write-cgi. Wenn man dafür jetzt ein *.tar.gz mit einfachen Instruktionen wie
./configure
make
make install
machen würde, wäre ja alles gut.
UND NEIN ICH SPRECHE NICHT VOM KOMPILIEREN FÜR ALLE BELIBIGEN DISTRIBUTIONEN ETC
Der Nachteil beim herunterladen und kompilieren des ganzen bcusdk sind mögliche Konflikte mit dem installierten eibd. Wir wollen ja nicht, dass der User sich seine funktionierende eibd installation zerschiesst.
Hatte Makki am 1.4.2010 probiert, vgl. bcusdk-Mailingliste.
Ich weiss.
Code:
Die beiden Dateien sind - wie in der README beschrieben - in das bcusdk-Paket hineinzukopieren und zu kompilieren.
Die README muss ich übersehen haben.
Ich habe aber auch genau das gemacht. Ergebnis: die Dateien werden nicht kompiliert.
=> Wer das bcusdk Kompiliert, was man für den eibd ja sowieso machen muss, kommt ohne jegliche Probleme auch an eibread-cgi/eibwrite-cgi
Mit dem tar.gz von Makki: Ja, mit dem offiziellen und reinkopierten Dateien nicht (ich zumindest).
Wer schon einen vorgefertigten eibd nimmt, müsste bei dem Nachfragen der den bereitstellt - oder eben doch selber kompilieren.
Genau. Und letzteres möchte ich eben leicht machen, so dass er eben nur diese zwei mini-progrämmchen kompiliert. Kann doch nicht so schwer sein.
Das hat alles nichts mit WG oder nicht-WG zu tun. Das ist eine Distributions-Frage.
Nichtmal. Eigentlich sollte es distributionsunabhängig sein, wie man zwei *.c kompiliert, oder?
Naja, die entsprechenden Header-Dateien des bcusdk wird's immer brauchen - denn in denen ist die API für den eibd drinnen.
=> Ohne bcusdk-Paket machts keinen Sinn
Hm, das wusste ich nicht. Gibt es wirklich keine kompakte Möglichkeit? Kann man die Header nicht mitliefern? Wie läuft das bei anderen Programmen, die auf die API eines anderen Programms zugreifen? Es können ja auch zwei Programme auf die API eines Programms zugreifen, z.B. beim Kernel. Muss doch gehen.
Das rrdtool haben wir schon erledigt und für den eibd (incl. eibread/write) gibt es Debian x86 und armhf packages ... wo liegt denn das eigentliche Problem?
Nicht jeder hat Debian, manche haben 64bit usw.
Deshalb sollten wir -wie es auch in meinen Augen allgemein üblich ist- erklären, wie man den Kram kompiliert und fertig. Das ist ja auch Grundvoraussetzung für Packete.
Das ist aber allgemein eher unüblich würde ich behaupten, gängiger ist es gegen vorhandende Header eines anderen Pakets zu kompilieren. Die kann man entweder vorrausetzen ("bcusdk-dev"?) oder gleich "mitbringen", dann aber eben nicht das ganze Paket sondern nur die Header.
Jetzt kommen wir der Sache schon näher. Das muss doch gehen?
Wenn das nicht jmd anderes schon gemacht hat, werde ich die nächsten Tage mal die Machbarkeit prüfen.
Also soweit ich die includes und die BCUSDK Doku verstehe braucht man um einen Client zu kompilieren lediglich die common.h eibclient.h und muß gegen eibclient (libeibclient.a) linken. Das wäre wirklich trivial...
libeibclient.a kommt beim Wiregate im Paket libeibclient-dev mit, ich gehe mal davon aus, dass andere Distis das ähnlich machen und man das als Abhängigkeit hinnehmen kann. Müßten wir also nur common.h eibclient.h und aufnehmen und ein Makefile drumherum packen.
Es sieht allerdings so aus, als wenn aus eibread/write-cgi auch noch Funktionen aus "Common" mitbenutzt werden, das ist erstmal keine BCUSDK Abhängigkeit "an sich", aber wenn wir die Funktionen brauchen, müssen wir auch noch common.o verlinken (vergleiche Makefile im examples Verzeichnis). Für common.o wiederum braucht es noch ein bißchen mehr (bcusdk/common).
Nichtmal. Eigentlich sollte es distributionsunabhängig sein, wie man zwei *.c kompiliert, oder?
Das Kompilieren: klar. Aber nicht wo welche Dateien mitgeliefert werden, das entscheidet jede Distribution für sich.
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Also mit Makefiles freunde ich mich nicht mehr an, aber es funktioniert per "Hand". Werde gleich mal die drei Dateien und ein modifiertes README einchecken. Wer dann dazu noch ein passenden Makefile erstellen mag ist herzlich eingeladen ;-)
Mit den Dateien die ich jetzt einchecke reichen folgende drei Zeilen (Vorraussetzung sind libeibclient-dev und natürlich gcc):
Damit erhält man eibread-cgi und eibwrite-cgi passend zu einem bereits (z.B. Distri-seitig) installierten EIB (dynamisch gelinkt gegen libeibclient.so).
Deinen Einsatz in allen Ehren, aber der Commit geht IMO zu weit.
Du kannst doch nicht den Header zu einer von einer anderen Stelle kommenden binären Bibliothek einchecken?!?
Die Header-Dateien gehören exakt zu der konkreten kompilierten Bibliothek, alles andere sorgt nur für Kopfschmerzen in der Zukunft!
Nur weil jemand sich beim Einparken mit seinem Auto schwer tut, gibst Du ihm einen Panzer? Damit wird er schon in die Lücke kommen...
Ich finde schon das Bereitstellen von common.c/h unnötig da eibread-cgi/eibwrite-cgi nun mal eine direkte Erweiterung des bcusdk sind. Aber das ist wenigstens eine Blibliothek in der Bibliothek. Das steht für sich.
Aber einen Header getrennt von der Lib ist Wahnsinn.
(Bei einer Distribution mag das etwas anderes sein, die stellt extern die Binärkompatabilität sicher. Aber hier wird's ab einem der nächsten bcusdk-Versionen zum GAU kommen!)
=> Bitte nimm das schnell wieder raus, sonst muss ich es machen
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Sauber wäre die Dateien als eine Art Patch für das bcusdk im SVN zu halten.
D.h. die C-Sourcen dürfen gerne so bleiben, die Änderung an dem Makefile als Makefile.patch (oder von mir aus auch als Bash-Skript). Die aktuelle Version, die im README sagt, was man per Hand zu machen hat, ist aber eigentlich auch i.O.
Was anderes macht im SVN aus meiner Sicht keinen Sinn.
Um den Komfort bei den Anwendern zu erhöhen, kann man nun bei den SF-Dateien eine bcusdk-Version mit appliziertem Patch anbieten.
Damit ist aber meiner Meinung nach die Grenze von dem erreicht, was bei Open Automation liegen sollte.
Noch höherer Benutzer-Komfort sind nun noch fertig kompilierte Dateien. Diese sinst aber höchstgradig vom jeweiligen System abhängig, so dass die zur jeweiligen Distribution gehören und nicht mehr zu Open Automation selbst.
Man kann sich nun natürlich noch dafür entscheiden für gewisse gängie Systeme fertige Pakete bereit zu stellen. Aber da sehe ich immer die langfristige Wartung als schwierig an. Wie viele verwaiste PPA gibt's denn?
Für x86 gibt's die fertigen Paket ja schon bei ElabNET, die muss man sicher nicht spiegeln.
Für ARM und MIPS gibt's so viele Varianten (RPi, Fritz!Box, IP Extender, Synology, QNAP, ...), da dürfte man kaum glücklich werden.
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Was die common.h bzw common.c angeht gebe ich Dir (teilweise) recht, was die eibclient.h angeht *nicht* (außer der Tatsache, dass sie gar nicht im BCUSDK Verzeichnis stehen muß, da sie auch von libeibclient-dev mitgeliefert wird)
Siehe BCUSDK Doku, dort steht exakt:
EIBD includes a library holding a simple C implementation of its client protocol. It supports synchronous as well as asynchronous function calls. To use it, include eibclient.h and link with libeibclient.a.
Was common.h/c angeht gebe ich Dir recht, dass es nicht ideal ist, aber wenn Du nunmal aus eibread/write Funktionen aufgerufen werden, die in common enthalten sind, dann müssen sie nunmal irgendwie ins Paket kommen.
Grundsätzlich: Die Änderungen (eibd-clients) wurden vom Package-Maintainer anscheinend rejected oder ignoriert, wie auch immer. Zu behaupten sie gehören trotzdem dazu geht an der Realität vorbei. Ich sehe nur zwei Optionen
1) Eine "standalone" Version von eibd-clients (losgelöst vom bcusdk, aber natürlich trotzdem davon abhängig)
2) Einen fork von eibd, dann kann es auch ins examples rein.
Alles andere ist imho Bastelei auf Kosten potentieller Nutzer.
Interessant in diesem Zusammenhang evtl auch: Die Woche: Nicht nur für die Lieblings-Distribution entwickeln! | heise open
(Ein Paket in der derzeitigen Form, als Anhang von BCUSDK obwohl es Upstream nicht enthalten ist würde von *jeder* gängigen Distribution rejected werden)
Du kannst doch nicht den Header zu einer von einer anderen Stelle kommenden binären Bibliothek einchecken?!?
Mache ich auch gar nicht. Ich linke 1) gegen eine andere Bibliothek, dafür ist sie ja da und 2) zeige ich zu zwei includes die vom Author vom eibread/write nunmal benutzt wurden, das läßt sich nicht wegdiskutieren
Nur weil jemand sich beim Einparken mit seinem Auto schwer tut, gibst Du ihm einen Panzer? Damit wird er schon in die Lücke kommen...
Diese Metapher sehe ich für den derzeitigen Fall viel gravierender. Nur weil eibd-clients Upstream nicht akzpetiert wurden braucht man nun das gesamte bcusdk Paket um zwei kleine cgi's zu kompilieren?
Aber einen Header getrennt von der Lib ist Wahnsinn.
(Bei einer Distribution mag das etwas anderes sein, die stellt extern die Binärkompatabilität sicher. Aber hier wird's ab einem der nächsten bcusdk-Versionen zum GAU kommen!)
Das ist (siehe bcusdk Doku) genau so vorhergesehen. Üblicherweise löst man bei dynamischer Verlinkung das ganze mit verschiedenen Versionen, d.h. wenn nicht mehr ABI-kompatibel dann höhere Version.
Davon abgsehen, hast Du mal in die common.h/c reingeguckt? Da drin ist nur GA parsing defniert, ein paar Helperfunktionen die mal NULL Abhängigkeit von irgendeiner eibd Funktion haben. Die Funktionen könnte man genauso gut selbst implementieren, aber warum nicht ein paar Code-Snippets von irgendwo anders nehmen...
EIBD includes a library holding a simple C implementation of its client protocol. It supports synchronous as well as asynchronous function calls. To use it, include eibclient.h and link with libeibclient.a.
Für mich ist das eine klare Anweisung an den Programmierer, dass der per #include die Datei eibclient.h in seinem Code einfügen soll und dem Linker sagt, die libeibclient.a mit zu linken.
Für mich ist das nicht die Anweisung, eibclient.h mit dem eigenen Code mit auszuliefern.
Wäre das gewollt, dann würde man in letzter Konsequenz auch stdio.h mit ausliefern müssen...
Was common.h/c angeht gebe ich Dir recht, dass es nicht ideal ist, aber wenn Du nunmal aus eibread/write Funktionen aufgerufen werden, die in common enthalten sind, dann müssen sie nunmal irgendwie ins Paket kommen.
Da diese Dateien sonst keine Abhängigkeiten haben, sehe ich hier kein Problem die mit auszuliefern. Da kann nicht viel kaputt gehen.
Ob es jetzt geschickt oder ungeschickt ist die mitzuliefern ist ein anderes Thema
Grundsätzlich: Die Änderungen (eibd-clients) wurden vom Package-Maintainer anscheinend rejected oder ignoriert, wie auch immer.
Martin wünschte sich ein paar Verbesserungen, bevor er die aufnehmen würde. D.h. wenn man den Code entsprechend verbessern würde, könnte der wohl aufgenommen werden.
Zu behaupten sie gehören trotzdem dazu geht an der Realität vorbei. Ich sehe nur zwei Optionen
1) Eine "standalone" Version von eibd-clients (losgelöst vom bcusdk, aber natürlich trotzdem davon abhängig)
2) Einen fork von eibd, dann kann es auch ins examples rein.
Richtig. Bei 1) darf aber nicht der Header mit rein, der ist eine Abhängigkeit.
Bei 2) kann man auch nur den Patch im SVN pflegen und das gepatchte Paket bei den Downloads mit anbieten.
Da läßt sich drüber diskutieren, mit removal zu drohen halte ich aber nicht für die feine englische Art
Ich denke wir sind sehr liberal, was die Commits angehen. Aber wenn Schaden droht, muss ich schon einschreiten. Da er nicht unmittelbar ist, hab ich's ja auch nicht selber gelöscht
Du kannst doch nicht den Header zu einer von einer anderen Stelle kommenden binären Bibliothek einchecken?!?
Mache ich auch gar nicht. Ich linke 1) gegen eine andere Bibliothek, dafür ist sie ja da und 2) zeige ich zu zwei includes die vom Author vom eibread/write nunmal benutzt wurden, das läßt sich nicht wegdiskutieren
Doch, machst Du.
Gegen andere Bibliotheken zu linken ist natürlich klar.
Aber die Header gehören zur Bib und nicht zum nutzenden Code!
Das mag genau jetzt funktionieren, aber bei möglichen Änderungen in der Zukunft wird man auf die Schnauze fallen können
Einer von uns beiden hat das Prinzip von dynamischer Verlinkung nicht verstanden.
Mal davon abgesehen das .a statisch und nicht dynamisch (das wäre .so) sind, ist das hier nicht relevant. (Ohne auf das Thema "verstanden" hier einzugehen)
Davon abgsehen, hast Du mal in die common.h/c reingeguckt? Da drin ist nur GA parsing defniert, ein paar Helperfunktionen die mal NULL Abhängigkeit von irgendeiner eibd Funktion haben. Die Funktionen könnte man genauso gut selbst implementieren, aber warum nicht ein paar Code-Snippets von irgendwo anders nehmen...
Richtig, daher macht die auch keinen Schaden und kann von mir auch auch bleiben.
Drohung ist was anderes. Und natürlich auch erst mal diskutieren (sonst hätte ich's gleich gesprochen).
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Sowohl die libeibclient.a (statische Bilbliothek, wird benötigt zum Zeitpunkt des Kompilierens, war nie Teil meines Commits), die eibclient.h (als Schnittstellen/API-Beschreibung) als auch libeibclient.so (gegen die dann letztendlich verlinkt wird, wird zur Runtime benötigt, war nie Teil meines Commits) sind im libeibclient-dev Paket von Hause aus enthalten.
Die tatsächlich unnötigerweise enthaltene eibclient.h habe ich ja anstandlos (und wie in meinem vorletzten Posting erwähnt) bereits entfernt.
Martin Kögler hatte übrigens vorgeschlagen dass nach Bereinigung höchstens in "contrib" aufzunehmen. Ich denke die Funktion der CGIs sind auch zu speziell um das tatsächlich als "example" durchgehen zu lassen.
Hatte sich eigentlich nach der Version die Makki eingeschickt hat und der "heutigen" Version nochmal was am Code getan? Das war ja doch recht heftige (und berechtigte) Kritik in Martin's Antwort.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar