DLL's und einbinden von C++Code

' 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