macOS: VW 2022 SDK plugin compilation issues

[Richard1]

I'm trying to upgrade our existing Vectorworks plugin to support 2022.

On Windows this was very simple, I just added an extra configuration that configured the paths and libs for the 2022 SDK instead, and this works just fine (with the same caveats as before that the VW SDK .props file must be imported before anything else)

 

On macOS, adding the new Target appears to compile but does not result in a working plugin on either Intel or M1 Macs, whether forced Rosetta2 or not. (Big Sur and Monterey)

 

Our plugin uses Qt5, and it looks like the loader paths have changed for this.
I've tried updating them to the same Qt5 loader path used by the Vision dylibs that ship with VW2022 SP1.1, but this still does not work on any platform.

 

How can I determine what is preventing the macOS edition of the plugin from loading?

Edited November 18, 2021 by Richard1

[Hippocode]

Make sure you are compiling with at least 10.15, target should be 10.13. If you still have an issue I find the easiest way to tackle this is to start fresh from a sample project and copy over your custom files and settings. Old projects can contain deprecated settings and after a while it's hard to find what is used and what not. Also make sure you compile generic to cover both ARM64 and Intel.

 

 

 

[Richard1]

Thanks.

The main issue I seem to have is linking and loading an appropriate set of Qt libraries.

 

I haven't been able to prove this yet, so it may be something else.

Edited November 19, 2021 by Richard1

[Stefan Bender]

I think quicktime support was removed from the SDK some versions ago.

[Richard1]

Qt, not Quicktime.

Vectorworks uses Qt for some things. 2022 SP1 ships with Qt 5.12.10 on macOS.

 

Our plugin uses Qt as well so we need to ensure our plugin loads the ones provided by Vectorworks.

[bbudzon]

Not sure how much help I'll be, but I can try to clarify some things at least and try to get you going in the right direction!

 

So, the Qt version that we are using (as you point out) is Qt 5.12.10.

 

When you look at a Windows build of VW/Vision, you will notice that the Qt header files are not included. This is mostly because they are not necessary at runtime and no additional work needs to be done to avoid including these headers.

 

So, in order to build against the appropriate Qt version on Windows, you can follow the same steps we do internally. Simply download Qt 5.12.10 for Windows off of the Qt website and install this. The installation will provide you with both the libraries and header files necessary to compile/link. Since Windows is always Intel-only, there is no reason we cannot use the packages shipped directly by Qt. You also do not have to worry about some of the pathing stuff I will discuss below at runtime as all DLLs are assumed by windows to be "next to the exe".

 

When you look at a MacOS build of VW/Vision, you will notice that the Qt frameworks are included in their entirety. On MacOS, a framework includes not only the library but the header files as well. This works out really well for you as a lot of work was put into preparing MacOS Qt Frameworks for Intel and M1.

 

I haven't tested this. So, I could be wrong. But, I'd think that on MacOS you would be able to simply compile and link against the Qt frameworks we ship with VW/Vision. These frameworks include the headers which are necessary for compilation and the libraries which are necessary for linking. I can't see any reason why this wouldn't work, in theory. In practice is another story!!

 

There is one last "requirement". But, this is a runtime requirement; not a compile-time / link-time requirement. MacOS must be able to locate all library dependencies at runtime so that they can be preloaded when launching the application. If you inspect the SpotlightVision plugin with otool, you will notice its runtime pathing is setup for Qt as "@executable_path/../../../Frameworks/Vision/QtCore.framework/Versions/5/QtCore" (for example). If you do not have this pathing setup correctly, then the plugin will fail to load at runtime due to missing dependencies. Again, none of this pathing would affect compilation or linking; only runtime.

 

I hope this clarifies some things for you and I hope you get up and running without too many more issues!! I'll try to answer any questions you might have when I can find time.

[Richard1]

Thanks bbudzon.
That is the rpath I tried in my Dec 8th build, so I guess that's probably correct and not the cause of the remaining issues.

 

I'm rather surprised that Vectorworks haven't tested building a Qt-based plugin using the published SDK and VWX/Qt libraries.

Can this test step please be added to your pre-release process, and the necessary build steps documented in the SDK?

Edited February 7, 2022 by Richard1