LabVIEW.lib linking

[JamesMc86]

Manager and other LabVIEW functions require linking to LabVIEW.lib in the relevant LabVIEW installs cintools folder.

The detection and linking of this will probably either need:

• Including in the crate build process (but how would a user specify the LabVIEW version)
• Provide a function for doing this in the client library easily so they can link to a specified LabVIEW version
• Create a labview-sys crate versioned to labviews version - can a user of labview-interop then specify the version?

[JamesMc86]

Done a first version where:

• Modules individually link to the desired functions.
• Users of the library must provide a link path in their build.exe to their version of LabVIEW.

Is the produced item forward compatible? Probably no guarantees.

Looked at dynamic loading such as demonstrated in JKISoftware/toml-edit-labview#3 but moved to the simpler route to start as I couldn't dynamically load with just the library name like I thought might work. Jim does point out a way in that issue to do it with current exe which is a nice route.

All-in-all needs a little more thought still

[JamesMc86]

If we wanted dynamic linking then the ctor crate looks like the answer to avoid complexity on the first call: https://docs.rs/ctor/latest/ctor/

The obvious downside will be performance though, if we centrally create this do we need thread-safe structures? Is there a way to abstract this so it can be an option to do stator or dynamic.

Why Not Just Static?

Static is preferred so why not just static.

1. I need to test for compatibility across LabVIEW versions.
2. Requires LabVIEW to be present at build time meaning it must be on CI servers etc. which can be restrictive. But this may be needed for testing anyway.

[JamesMc86]

This looks like exactly what we need for runtime loading of the labview functions: https://crates.io/crates/dlopen

[JamesMc86]

Done this with ctor and dlopen2 (since dlopen is unsupported)