eibread/wrige-cgi kompilieren

[ctr]

Sollte wie in meinem Post beschrieben Standalone kompilierbar sein, Voraussetzungen siehe Readme

[henfri]

Hallo,

was ist denn nun die interim-Lösung? Ich habe da nicht ganz mithalten können in eurer Diskussion und hätte jetzt einen Anwendungsfall, wo ich es testen könnte.

Gruß,
Hendrik

[Chris M.]

Ich denke auch, dass die Aufnahme im bcusdk das Ziel sein muss.
Die geforderten Änderungen sind ja auch nicht wirklich willkürlich...

Ob das dann ein Install-Target wird oder nicht kann man dann sicher noch mal diskutieren. Die Zeit die beiden Dateien zu kompilieren ist ja sehr übersichtlich und der benötigte Platz auch. Ich sehe da wenig Grund voreilig zu optimieren.

[ctr]

Das werde ich mir tendenziell mal angucken, allerdings hatte er auch angedeutet, dass er es selbst dann nur in contrib bzw als build-only binaries (ohne install-target) aufnehmen würde. Beides ist imho langfristig keine gute Idee, weswegen ich immernoch für ein eigenes "Paket" cometvisu-eib-clients (oder ähnlich) votieren würde.
Dieses könnte im OpenAutomation gepflegt werden und - wenn ordentlich dokumentiert - vielleicht sogar mal den Sprung in eine Distribution finden.

[greentux]

Soweit ich der bcusdk liste folgen konnte, wäre das sauberste, die beiden Programme zu fixen. Dann wird sie Kollege Kögler schon aufnehmen.
Er hatte hier
SourceForge.net: BCU SDK with eibd:
ja ein paar Anmerkungen, auf die keine Antwort mehr kam.

Da bräuchte es also einen C-affinen Entwickler, der das säubert. Denn generell wurde es nicht abgelehnt.

[Chris M.]

Keine, die ich bemerke. Und ich habe eigentlich nur MS Office. Alles andere ist nicht von MS. Egal.

Wikipedia ist's zumindest einen Artikel wert: https://de.wikipedia.org/wiki/DLL-Konflikt

Und wie so oft: das ein System läuft, sagt bei Software leider überhaupt nichts aus. Es geht darum, dass es auf allen Systemen läuft.
Was passiert, wenn man sich nicht darum kümmert: -> Lese in diesem Forum mal ein paar Beiträge zur ETS4 Installation...

Ok. Unsere Abhängigkeit ist also ein installierter my_dmx_client&daemon.
Richtig? Und der liefert seine Header Dateien mit und (irgendwie) findet unser Programm die.
Hab ich das richtig verstanden?

Jain.

Wir hätten hier eine Abhängigkeit zu einer Bibliothek.
Um beim kompilieren Deines Programmes diese Bibliothek nutzen zu können, muss neben der Bibliothek selbst auch die Header-Datei dieser Bibliothek mitgeliefert werden.

Wenn Du nun statisch linkst, muss zur Laufzeit Deines Programms nichts mehr mitgeliefert werden, das einzelne Binary ist genug (unter Windows wäre es das .exe).
Wenn Du dynamisch linkst, muss zur Laufzeit neben Deinem Programm auch noch die dynamische Version von exakt der Bibliothek vorhanden sein, mit der Du damals gelinkt hast (bzw. eine binärkompatible Version) - das wäre dann die .exe mit der .dll

Unter Debian (+ abgeleitete Systeme wie Ubuntu, WireGate, ...) wird das in der Regel so gehandhabt, dass eine dynamische Bibliothek foo in einem Paket libfoo bereitgestellt wird.
Wenn Dein Programm nun diese Bibliothek braucht und dynamisch gelinkt hat, dann wäre es mit dem gleichen Kompiler erstellt worden und hätte libfoo als Abhängigkeit in der Paketverwaltung eingetragen. Dadurch ist sichergestellt, dass die Versionen zusammen passen und die Bibliothek installiert wird, sobald Dein Paket installiert wird.

Wenn Du nun selber Dein Programm kompilieren möchtest (z.B. auf einem Entwicklungs-System wo es noch keine Pakete dafür gibt), dann müsstest Du nach Konvention noch das Paket libfoo-dev installieren - dort liegt nun die Header-Datei für foo drinnen. Evtl. liegt da auch noch eine Version der Bibliothek foo drinnen, die die Debug-Infos enthält, so dass man beim Stacktrace u.ä. man eine Chance hat rauszufinden, wo man ist.

Wenn nun das Programm so weit fertig ist, dass es als Paket in die Distribution mit aufgenommen wird und/oder Du die Bibliothek selbst übersetzen möchstest, dann gibt es dafür noch die Source-Pakete über die man im Rahmen der Paket-Verwaltung selbst übersetzen kann
(Wie das genau geht, kann ich nicht sagen, habe ich noch nie genutzt - bin halt eher Entwickler als Administrator; die machen das genau umgedreht, die bauen sich, sollten sie selber Code schreiben müssen, als erstes ein Paket und übersetzten den Code im Paket...)

Vgl. auch

• https://de.wikipedia.org/wiki/Bin%C3...-_und_Software
• https://de.wikipedia.org/wiki/Bin%C3...tibilit%C3%A4t
• https://de.wikipedia.org/wiki/Biblio...grammierung%29

[henfri]

Wenn Du nur Microsoft Produkte laufen hast, dürfte es meist funktionieren.
Sobald Du allerdings Programme von anderen Herstellern installierst, wird es früher oder später zu Problemen kommen.

Keine, die ich bemerke. Und ich habe eigentlich nur MS Office. Alles andere ist nicht von MS. Egal.

Das ist simpel:
Du definierst eine Abhängikeit (im Text der Doku) und erwartest das der, der Kompiliert, diese Abhängikeit erfüllt. Denn sonst wird es einfach nicht kompilieren - spätestens wenn der Compiler die per #include eingebundene Header-Datei nicht findet. Oft bereits vorher beim ./configure (so man die Autotools nutzt)

Ok. Unsere Abhängigkeit ist also ein installierter my_dmx_client&daemon.
Richtig? Und der liefert seine Header Dateien mit und (irgendwie) findet unser Programm die.
Hab ich das richtig verstanden?

Gruß,
Hendrik

[Chris M.]

Ganz ehrlich:
Ich hatte die Probleme, die wir hier haben -zumindest bewusst- in Windows noch nie. Vermutlich weil es nur eine "Distribution" gibt und weil es dafür Packete gibt.

Wenn Du nur Microsoft Produkte laufen hast, dürfte es meist funktionieren.
Sobald Du allerdings Programme von anderen Herstellern installierst, wird es früher oder später zu Problemen kommen.

Such mal bei Google nach msvc... - bei msv kommen schon lauter DLLs als Such-Vorschlag und bei msvc die einschlägigen Suchergebnise wie "Fix “The program can't start because MSVCR100.dll is missing from ..." oder "The PROPER way to fix msvcr100.dll, msvcr100d.dll or d3dx9_*.dll ...".
Das tückische an diesen DLLs hier ist, dass die die Laufzeit-Umgebungen für Visual C enthalten, d.h. quasi jedes Programm die braucht. Und die sich bei Updates oder Bugfixes vom Visual C wohl gerne erneuern können. (Mein letztes Visual C++ Programm ist aber nun etliche Jahre her, d.h. wie's aktuell genau ist, kann ich nicht sagen)

Selbst die hier im Forum beschriebenen ETS4 Installations- und Lauf-Probleme könnte ich mir gut darin begründet vorstellen.

Und was ist bei:
"Du lieferst Source aus"? Darum geht es doch.

Das ist simpel:
Du definierst eine Abhängikeit (im Text der Doku) und erwartest das der, der Kompiliert, diese Abhängikeit erfüllt. Denn sonst wird es einfach nicht kompilieren - spätestens wenn der Compiler die per #include eingebundene Header-Datei nicht findet. Oft bereits vorher beim ./configure (so man die Autotools nutzt)

[henfri]

Hi Chris,

vielen Dank für deine ausführliche Antwort!

Aber wehe wenn Du die Deinem Compilat nicht mitlieferst (erst recht wehe Du machst das und überschreibst eine Version die schon auf dem System liegt!) - dann läuft das Programm im glücklichen Fall nicht. Im unglücklichen verwendet es eine falsche Version.
Windows ist da etwas hemdsärmlich unterwegs (gewesen?) - und hat dadurch den Begriff DLL-Hell begründet...

Ganz ehrlich:
Ich hatte die Probleme, die wir hier haben -zumindest bewusst- in Windows noch nie. Vermutlich weil es nur eine "Distribution" gibt und weil es dafür Packete gibt. Ist hier aber keine Alternative (s.u.)

Kurz zusammengefasst:
Du lieferst Binaries aus und kennst das Ziel-System höchstens grob: linke statisch
Du lieferst Binaries aus und kennst das Ziel-System genau (z.B. weil Du eine Distribution erstellst): dynamisches Linken ist eine Option

Und was ist bei:
"Du lieferst Source aus"? Darum geht es doch.

Gruß,
Hendrik

[Chris M.]

Die tatsächlich unnötigerweise enthaltene eibclient.h habe ich ja anstandlos (und wie in meinem vorletzten Posting erwähnt) bereits entfernt.

Übersehe ich mal das anstandslos: das war das was ich erreichen wollte. Der Rests liegt irgendwo zwischen Präferenz, Schule, Geschmack, ... - und da will ich nicht streiten, höchstens meine Meinung kund tuen. Entscheiden darf hier der, der sich die Arbeit macht - wie bei OSS üblich.

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.

Ich weiß es nicht, da hatte ich mich nie drum gekümmert.
Mein Ziel wird die beiden Progrämmchen nicht brauchen, die ich auch aus anderen Gründen ungeschickt finde. Aber stand jetzt ist das nun mal DIE Lösung, eine andere für die Allgemeinheit verfügbare, gibt's aktuell nicht.

darf ich nochmal fragen:
Ich möchte ein Programm schreiben, welches eine API von einem anderen Programm, z.B. my_dmx_client nutzt. Dieses Programm (my_dmx_client) ist häufig in Distributionen schon enthalten.

Wie gehe ich hier sauber vor?

Muss ich den Code des anderen Programm (my_dmx_client) mitliefern? Riskiere ich dann nicht, die Installation des my_dmx_client beim User zerschieße?

Das kommt darauf an...

Wenn es wirklich ein Programm ist, dann hängt das von der Schnittstelle ab, die dieses Programm anbietet. Hier sind wir sehr proprietär in dem Sinne, dass es keinen allgemeinen Standard dafür gibt.

Aber ich vermute, Du meinst das my_dmx_client eine Bibliothek ist (die z.B. mit my_dmx_cliend_deamon, einem Programm, kommuniziert). Diese Bibliothek wird üblicher Weise dadurch angesprochen, dass die Bibliothek eine Header-Datei mitbringt die Du per #include einbindest und dann die Bibliothek im Linker dazu linkst (würde dann z.B. libmy_dmx_client.a heißen).
Beim Linken kannst Du dann manchmal noch wählen ob statisch oder dynamisch.

Statisch macht Dein Programm dicker, sorgt aber dafür, dass es auch auch unbekannten Systemen meist schmerzfrei läuft.
Dynamisch macht das Programm schlanker und verbraucht weniger Ressourcen wenn mehrere Programme gleichzeitig laufen, die diese Bibliothek nutzen. Aber wehe wenn Du die Deinem Compilat nicht mitlieferst (erst recht wehe Du machst das und überschreibst eine Version die schon auf dem System liegt!) - dann läuft das Programm im glücklichen Fall nicht. Im unglücklichen verwendet es eine falsche Version.
Windows ist da etwas hemdsärmlich unterwegs (gewesen?) - und hat dadurch den Begriff DLL-Hell begründet...

Kurz zusammengefasst:
Du lieferst Binaries aus und kennst das Ziel-System höchstens grob: linke statisch
Du lieferst Binaries aus und kennst das Ziel-System genau (z.B. weil Du eine Distribution erstellst): dynamisches Linken ist eine Option

[henfri]

Hallo,

darf ich nochmal fragen:
Ich möchte ein Programm schreiben, welches eine API von einem anderen Programm, z.B. my_dmx_client nutzt. Dieses Programm (my_dmx_client) ist häufig in Distributionen schon enthalten.

Wie gehe ich hier sauber vor?

Muss ich den Code des anderen Programm (my_dmx_client) mitliefern? Riskiere ich dann nicht, die Installation des my_dmx_client beim User zerschieße?

Gruß,
Hendrik

[ctr]

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.

[Chris M.]

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.

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)

Nur weil eibd-clients Upstream nicht akzpetiert wurden braucht man nun das gesamte bcusdk Paket um zwei kleine cgi's zu kompilieren?

So groß ist das bcusdk doch auch nicht. War, glaub ich, unter einem MB...

Aber einen Header getrennt von der Lib ist Wahnsinn.

Das ist (siehe bcusdk Doku) genau so vorhergesehen.

Nein, da hast Du was verwechselt. Zur Bedeutung des Textes: s.o.

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 unnötig, bitte erst diskutieren.

Drohung ist was anderes. Und natürlich auch erst mal diskutieren (sonst hätte ich's gleich gesprochen).

[ctr]

Und nochmal im Detail

Deinen Einsatz in allen Ehren, aber der Commit geht IMO zu weit.

Da läßt sich drüber diskutieren, mit removal zu drohen halte ich aber nicht für die feine englische Art

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

Die Header-Dateien gehören exakt zu der konkreten kompilierten Bibliothek, alles andere sorgt nur für Kopfschmerzen in der Zukunft!

Einer von uns beiden hat das Prinzip von dynamischer Verlinkung nicht verstanden.

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?

Ich finde schon das Bereitstellen von common.c/h unnötig da eibread-cgi/eibwrite-cgi nun mal eine direkte Erweiterung des bcusdk sind.

Das sieht der bcusdk Author wohl anders.

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

=> Bitte nimm das schnell wieder raus, sonst muss ich es machen

Drohung unnötig, bitte erst diskutieren.

[ctr]

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)