Dynamically determine value of use_tmpcpy based on library version

[bbrown1867]

Instead of defaulting this value to True, this change changes pylink to dynamically determine based on DLL version.

Closes #32 and #134.

[CLAassistant]

All committers have signed the CLA.

[hkpeprah]

LGTM!

[mtnpke]

This broke debugging with multiple targets, as the new default only allows one target and is thus backwards-incompatible. Even worse, if you open multiple JLink instances, it will just silently reuse the same DLL instance and thus the same target, resulting in all sorts of weird and hard-to-debug errors. It's also not clear from the documentation that you have to set this if you want multi-target. All in all: Are you sure this is a good idea?

[hkpeprah]

@mtnpke Could you post the error you are seeing? The newer DLL / DYLIBs should support multi-target debugging / multiple instances.

[mtnpke]

@hkpeprah There is no error in the sense that I could post one specific message. If you open two connections, the DLL calls of the second will just "overwrite" the state of the first connection. So if you connect two J-Links, after opening the second connection, you would not be able to control the first target any more (or the second depending on your exact connection flow, e.g. if you check for an open connection).

Why do you think the newer DLL should be multi-target capable? The API has not changed and it does not have a "handle" parameter for selecting a connected target, so it is already impossible to do this on the API level 🤔 Besides, the guidance in UM08002 has not changed and still says (as of 8.32) that parallel connections are not natively supported.

[hkpeprah]

In earlier DLL, there was a global "lock" that prevented simultaneous access to the DLL. The temporary copy was a workaround for the global "lock", and we implemented our own lock around the specific physical device. Later that global lock was removed. I naively assumed that was the thing preventing parallel connections, but it seems like that's not the case.

I agree with you that we broke things here and need to come up with a solution that copies not only the DLL, but also the necessary additional metadata spattered around .xml files.

[mtnpke]

Ah OK, I was not aware of this earlier limitation on Linux and Mac OS; however, it is how you already said just a piece of the puzzle and not the root of the limitation (also, from what I can tell this never affected Windows).

I don't know if you have access to UM08002 (you can find some old but sufficiently recent versions in the WWW), but it specifically recommends to either copy the DLL or have separate processes dealing with multiple connections as workarounds. It does not say anything about the additional metadata. The example for DLL copies is Windows-only and copies the DLL inside its original directory, which really only makes sense if you ship the DLL yourself alongside the .exe and only ever run one instance of your app. Otherwise you're bound to have access rights and concurrent access issues.

IMO, going back to the old behavior of having the temporary copy be the default would already be a big improvement over the status quo. Alternatively, globally keeping track of whether a pylink.JLink instance is in a connected state and raising an exception if a user tries to open a second connection (without temporary copy) would alleviate the pain insofar that you'll be saved some unnecessary debugging hours.