eibread/wrige-cgi kompilieren

[Chris M.]

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.

[henfri]

Hallo Chris,

was wäre denn das korrekte Vorgehen?

Gruß,
Hendrik

[Chris M.]

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

[ctr]

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):

gcc -leibclient -c bcusdk-include/common.c
gcc common.o -I./bcusdk-include -leibclient -o eibwrite-cgi eibwrite-cgi.c
gcc common.o -I./bcusdk-include -leibclient -o eibread-cgi eibread-cgi.c

Damit erhält man eibread-cgi und eibwrite-cgi passend zu einem bereits (z.B. Distri-seitig) installierten EIB (dynamisch gelinkt gegen libeibclient.so).

[Chris M.]

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.

Hast Du auch die Makefile gepatcht?

 6  * Adjust Makefile.am:        
 7  -xpropread xpropwrite groupcachelastupdates        
 8  +xpropread xpropwrite groupcachelastupdates eibread-cgi eibwrite-cgi 
 9    
10  -xpropread.c xpropwrite.c groupcachelastupdates.c        
11  +xpropread.c xpropwrite.c groupcachelastupdates.c eibread-cgi.c eibwrite-cgi.c

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.

[henfri]

Das hört sich doch gut an!

[ctr]

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).

[henfri]

Hendrik, nun mal langsam ... komm mal runter.

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.

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.

Super!
Danke!

Gruß,
Hendrik

[ctr]

eibread/wrige-cgi kompilieren

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.

[JuMi2006]

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?

[swiss]

@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.

[Chris M.]

Das sollte nur zeigen, dass die Dateien Upstream NICHT enthalten sind.

Hatte Makki am 1.4.2010 probiert, vgl. bcusdk-Mailingliste.

Es ist nunmal so, dass die CV NICHT rein für das WG gedacht ist, es aber momentan nicht einfach ist, die zwei mini-Programme zu kompilieren.

Die beiden Dateien sind - wie in der README beschrieben - in das bcusdk-Paket hineinzukopieren und zu kompilieren.
=> Wer das bcusdk Kompiliert, was man für den eibd ja sowieso machen muss, kommt ohne jegliche Probleme auch an eibread-cgi/eibwrite-cgi

Wer schon einen vorgefertigten eibd nimmt, müsste bei dem Nachfragen der den bereitstellt - oder eben doch selber kompilieren.

Das hat alles nichts mit WG oder nicht-WG zu tun. Das ist eine Distributions-Frage.

ICH habe mir viel Arbeit gemacht, eine Dokumentation für die Installation zu erstellen und ich meine, es fehlt nur noch das kompilieren dieser zwei Programme.

Dafür auch vielen Dank!

Was sind die Voraussetzungen (Dependencies, brauche ich das ganze bcusdk?)? Kann nicht einfach eine Makefile für nur die beiden Dateien gemacht werden?

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

[JuMi2006]

Hendrik, nun mal langsam ... komm mal runter.
Wir arbeiten hier mit Häppchen von Informationen und hangeln uns über Tage und Threads hinweg um jeglichem Linux DAU zu helfen...weil wir (ich) auch mal DAU war.

Aber ein wenig Hirnschmalz sollte jeder für ein gutes Produkt schon investieren. Dabei geht es jetzt nicht um die CV sondern generell. Mich nervt es auch dass die CV kein Release bekommt, aber ich mecker da nicht rum weil ich selbst keine Zeit investiere in dieses Projekt. Alles für lau und Pronto bitte als .deb ist da auch der falsche Weg (gesellschaftlich). Im von ctr verlinkten Beitrag steht doch sogar wie man es kompilieren kann.

Edit:
https://knx-user-forum.de/278971-post41.html

[henfri]

Ausgelagert ist es ja. Aber es ist nicht für jedes erdenkliche System kompiliert. Da heist es für "selber Bastler" nun mal selber kompilieren oder jemanden finden, der das kann.

Warum musst du denn in das extrem gehen (jedes erdenkliche)?
Die allermeisten OSS versuchen es dem Anwender leicht zu machen, sie zu nutzen.

Meist geht ein ./configure && make && make install
In einer Readme steht dann genau das drin.

Keiner sagt, dass es für jedes erdenkliche system kompiliert sein muss. Das hast du dir ausgedacht.

Ich sehe da nicht ElabNet in der Pflicht und eigentlich auch nicht das CometVisu Entwickler-Team.

Erstere nicht, leetztere auch nicht, da ja eh alles freiwilig ist.
Aber wenn ich möchte, dass jemand die SW nutzen kann, dann mache ich es möglichst leicht.

Eibd ist nicht so leicht zu kompliieren (Abhängigkeiten). Aber es gibt viele Packete dafür (s.o.) fehlen nur noch diese zwei Progrämmchen.

Aber wenn die CV dem Normalo vorenthalten bleiben soll, kann ich meine Anleitung auch gerne wieder löschen.

Gruß,
Hendrik

[swiss]

EDIT: Aber Ausgelagert ist es ja. Aber es ist nicht für jedes erdenkliche System kompiliert. Da heist es für "selber Bastler" nun mal selber kompilieren oder jemanden finden, der das kann.

Ich sehe da nicht ElabNet in der Pflicht und eigentlich auch nicht zwingend das CometVisu Entwickler-Team.

EDIT: Aber wenn du zum komplieren eine Anleitung verfasst oder für jede Distro ein Paket erstellst, haben alle etwas davon.