-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OPC DA: Switch to OPCClientToolKit with 64bit support #32
Conversation
Modified version of OPCClientToolKit as FORTE sub project: https://github.com/kumajaya/OPC-Client-X64/tree/master
The real problem was that I couldn't find a way to resolve the linking error in the OPCClientToolKit library and then discovered that making OPCClientToolKit as FORTE's OPC DA sub-project might be a better solution than building OPCClientToolKit library separately. |
You MUST NOT statically link or integrate OPCClientToolKit with 4diac FORTE. OPCClientToolKitis under LGPLv3 merging both would result in a license clash. |
So the OPCClientToolKit referenced by the 4diac documentation https://eclipse.dev/4diac/en_help.php?helppage=html/communication/opc.html has a licensing issues that need to be fixed, right? |
If done correctly everything is fine. We also submitted the dependency as works with dependency for legal clearance by the Eclipse Foundation, as is it is required for these kind of dependencies. However for updates, like yours a new clearance may be needed. Regarding done right: When using that lib you need to ensure that you are using it following both Eclipse 4diac's EPLv2 and OPCClientToolKit's LGPL license. |
Thank you for your good guidance, as always. Let me try to fix this licensing issue properly. Besides that, 64bit OPC DA working good on my Windows 11 so far. |
Upstream WS2LPCTSTR is buggy because on the initial 64bit port I can write but cannot read the OPC data values until I fix it. This local WS2LPCTSTR method is safe as it will always allocate the exact ammount of space needed for the conversion, resulting parsing OPC data item faster.
In my opinion no license issues anymore since I just use FORTE build system to build LGPL library from the outside FORTE source tree and then dynamically link it to the final FORTE binary. |
As you are upgrading a 4diac FORTE dependency from an Eclipse Foundation IP Team approved version to a newer version we need to perform a new IP audit for this update. Therefore I would kindly ask to let us know when the upgrade is complete so that I can start the process. Also for us I think it would be easier if you would squash all commits in this PR and open a new one. Normally we file IP dependency updates on specific releases of libraries. Currently I only see a reference to a Github fork of yours. Is there an official release with a version number for this change? |
Give me some time to test this upgrade in the next few days. I just found out how to completely disconnect from the server, this must be a memory leak bug as the server keeps connections until FORTE is restarted so we may have multiple connections when re-deploys. About OPCClientToolKit, my work is based on https://github.com/edimetia3d/OPC-Client-X64 but edimetia3d/OPC-Client-X64#8 says it currently doesn't have a maintainer. |
Then I'll wait till the completion of your improvement and will further investigate then how we can correctly and safely get that into 4diac FORTE. |
Just force pushed to https://github.com/kumajaya/OPC-Client-X64/tree/master without any specific changes for FORTE, currently incompatible to this patch. I will open a new PR with a squash commit. |
Modified version of OPCClientToolKit as FORTE sub project: https://github.com/kumajaya/OPC-Client-X64/tree/master