DLL's und einbinden von C++Code

' schrieb:Ok, ich glaub ich lass es. In diesem Forum wird sowieso nicht versucht einem mit seinem Problem zu helfen, sondern nur vorgeschlagen wie man es anders machen soll. Das ich evt. meine Gründe habe make zu verwenden scheint hier niemanden zu interessieren.

Hallo, Andreas,

du bist der allererste, der behauptet, dass einem im LVF NICHT geholfen wird. Das finde ich schon ein starkes Stück!

Bedenke bitte: wir arbeiten hier alle auf freiwilliger Basis, nur aus Spass und in unserer Freizeit! Du kannst hier nicht erwarten und erst recht nicht fordern, dass immer jemand eine Antwort auf DEINE konkreten Probleme zur Hand hat, vor allem, wenn man sie so ungenau und durcheinander stellt, wie du. (Nach dem Motto, was ist eine DLL, andererseits erstellst du offenbar DLLs, dann so Aussagen wie "...in eine DLL schreiben lassen?" Eine Dynamic Link Library sollte wohl, wenn einmal kompiliert, nicht mehr geändert werden). Es gab hier ein paar ganz konkrete Aussagen und Hilfen von rolfk und IchSelbst. Diese laufen ganz klar in folgende Richtung:
1. Eine CIN kannst du nicht mit C++ Code erstellen.
2. und viel wichtiger als 1. Vergiss das CIN-Konzept, es ist veraltet und wird wahrscheinlich bald nicht mehr supported. Ruf lieber direkt die Funktionen aus den DLLs auf. Je nach Übergabeparametern kann das zwar auch schwierig bis unmöglich sein, aber wir können nun auch nicht hellsehen, was du genau machen willst.

MfG, Jens

' schrieb:Hallo, Andreas,

du bist der allererste, der behauptet, dass einem im LVF NICHT geholfen wird. Das finde ich schon ein starkes Stück!

Bedenke bitte: wir arbeiten hier alle auf freiwilliger Basis, nur aus Spass und in unserer Freizeit! Du kannst hier nicht erwarten und erst recht nicht fordern, dass immer jemand eine Antwort auf DEINE konkreten Probleme zur Hand hat, vor allem, wenn man sie so ungenau und durcheinander stellt, wie du. (Nach dem Motto, was ist eine DLL, andererseits erstellst du offenbar DLLs, dann so Aussagen wie "...in eine DLL schreiben lassen?" Eine Dynamic Link Library sollte wohl, wenn einmal kompiliert, nicht mehr geändert werden). Es gab hier ein paar ganz konkrete Aussagen und Hilfen von rolfk und IchSelbst. Diese laufen ganz klar in folgende Richtung:
1. Eine CIN kannst du nicht mit C++ Code erstellen.
2. und viel wichtiger als 1. Vergiss das CIN-Konzept, es ist veraltet und wird wahrscheinlich bald nicht mehr supported. Ruf lieber direkt die Funktionen aus den DLLs auf. Je nach Übergabeparametern kann das zwar auch schwierig bis unmöglich sein, aber wir können nun auch nicht hellsehen, was du genau machen willst.

MfG, Jens

Dann bin ich halt der erste der sich beschwert. Es gibt immer ein erstes mal.
Und bei deiner Antwort (Punkt 2) schon wieder der Tip es in eine DLL zu packen. Das bringt mich kein Stück weiter denn ich verwende nunmal CIN weil es eine Vorgabe ist.

Danke an dc6xs. Werde mal woanders posten. Vieleicht hast du recht und es ist hier der falsche ort. Wünsche dir ebenfalls ein schönes WE.

' schrieb:Dann bin ich halt der erste der sich beschwert. Es gibt immer ein erstes mal.
Und bei deiner Antwort (Punkt 2) schon wieder der Tip es in eine DLL zu packen. Das bringt mich kein Stück weiter denn ich verwende nunmal CIN weil es eine Vorgabe ist.

Also, beschweren bei freiwilligen Antwortern kommt niemals gut an! Merk dir das! Das hat dir übrigens auch Rob (wenn auch etwas freundlicher als ich) schon gesagt.

Und erst in deinem letzten Beitrag rückst du klar und deutlich mit der Info heraus, dass du zwecks Vorgabe CINs verwenden musst. Davon war bisher NICHT die Rede.

Da darfst du dich nicht wundern, wenn dir erfahrene Leute Vorschläge machen, die mglw. nicht in deine Richtung gehen (schlag z.B. mal Rolf Kalbermatter bei Google nach, was der schon alles für LabVIEW-relevante Beiträge veröffentlicht hat).

Jens

' schrieb:Dann bin ich halt der erste der sich beschwert. Es gibt immer ein erstes mal.
Und bei deiner Antwort (Punkt 2) schon wieder der Tip es in eine DLL zu packen. Das bringt mich kein Stück weiter denn ich verwende nunmal CIN weil es eine Vorgabe ist.

Das Du CINs verwenden MUSST hast Du aber bis jetzt noch nicht erwähnt. Und selbst dann ist das meiner bescheidenen Meinung nach höchstens eine falsch verstandene Vorgabe oder noch schlimmer. CINs haben seit etwa LabVIEW 6 praktisch keinen einzigen Vorteil gegenüber der Erstellung von DLLs die Du von LabVIEW aus aufrufst und mit LabVIEW 8.20 wurden so ziemlich die letzten zwei (sehr esoterischen) Vorteile von CINs auch mit der Call Library Node möglich.

Falls Du Englisch lesen kannst darfst Du gerne auf http://expressionflow.com/category/external-code/ eine ausführliche Erklärung der Entstehung von CINs und warum man sie nicht mehr verwenden sollte lesen.

Technisch gibt es absolut keinen Grund mehr um CINs zu gebrauchen. Ihre Erstellung ist sehr LabVIEW spezifisch und selbst die meisten LabVIEW Programmierer bei NI selbst wissen nicht mehr wie das gehen muss, einfach weil es unnötig ist und keinerlei Vorteile bringt.

Gerne lasse ich mir von Dir ausführlich erklären warum Du denkst dass Du unbedingt ein CIN nötig hast aber ich kann Dir schon jetzt sagen dass es nicht einfach sein wird mich von der Notwendigkeit davon zu überzeugen und das ist nicht weil ich gegen CINs bin (ich war früher selber ein vehementer Verfechter von der Beihaltung des CIN Supports in LabVIEW).
Aber die Tatsache ist einfach dass die Erstellung davon umständlich ist, durch das spezifische LabVIEW make Script zwar noch unterstützt für ältere Compiler aber bei neueren Versionen musst Du oft genug selbst Hand anlegen weil es eben nicht mehr gepflegt und weiterentwickelt wird. Und für neue Plattformen wie etwa 64bit Windows und Unix (so die entsprechende LabVIEW Versionen dann irgendwann kommen) wird es GARANTIERT keine Unterstützung zur Erzeugung von CIN Code Resourcen mehr geben! Dann wirst Du doch alles auf DLLs umstellen müssen auch wenn Du jetzt denkst dass Dein Project niemals mehr angefasst wird nachdem Du es fertiggestellt hast.

Und zuletzt noch. Ich denke der Versuch plattformneutrale Makefiles zu machen ist zum Scheitern verurteilt. Die Microsoft Compiler haben nie versucht voll kompatibel zu sein zu anderen Toolchains und GNU hat nicht die Idee dass das was MS macht sinnvoll ist zu kopieren. MS hat seine Tools immer nur soweit kompatibel gemacht dass eine Migration von einer anderen Umgebung nach MS überhaupt möglich wird aber hat kein Interesse daran die Zurückkehr zu anderen Tools zu vereinfachen. Zudem ist es schon für die verschiedenen Versionen von MS Visual C eine echte Herausforderung um Makefiles zu machen die für mehr dann eine davon funktionieren.

Nicht ohne Grund hat NI zur CIN Erstellung unter Windows ein ntlvsb.mak File gemacht das in Dein *.lvm File eingebunden wird. Alle plattformabhängigen Dinge sind dort hineingesteckt und das LVM File war vorgesehen um der plattformunabhängige Teil der CIN Erstellung zu sein. Aber dieses ntlvsb.mak File ist ganz spezifisch für Visual C und da eigentlich für Version 6 gemacht. Ob das mit Cygwin funktioniert wie Du es zu versuchen scheinst wage ich mal ganz ganz fest zu bezweifeln. Gibt ja schon Probleme um das mit den neueren Visual C Versionen zu verwenden ohne etwas Anpassungen.
Und bereits mit LabVIEW für Linux haben sie diese Filosophie im wesentlichen verlassen und der Linuxversion ein spezifisches lvmkmf shell script beigefügt dass aus den lokalen Begebenheiten Deiner Installation direkt ein Makefile erstellt.

Was Du hier versuchst, ein plattformunabhängiges Makefile zur Erstellung von CINs zu machen, hat noch nicht mal jemand bei NI getan, soweit ich das beurteilen kann. Das wird zwar mit DLLs/Shared libraries auch nicht viel einfacher, aber dann bist Du zumindest nicht abhängig von ein paar ganz spezifischen CIN Begebenheiten die an Deinen Sourcecode und die Toolchain gestellt werden und verwendest Du zumindest keine esoterischen cintools Kommandlinetools die mit Deinen compilierten Objektfiles nicht so einfach nachvollziehbare Dinge anstellen, um sie in ein lsb File zu massieren.

Rolf Kalbermatter