eibread/wrige-cgi kompilieren

[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

[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]

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

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]

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

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

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

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

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

[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

[ctr]

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