Provide dynamic framework for cmake / direct clang usage

[ptxmac]

It seems the new xcframework type is only supported with xcode. Users wanting to compile with clang need a "normal" framework with dynamic libraries instead.

One solution is to install the dylib in a linker search path, but that only work when there's full control of the compile process.

Libraries like vulkan-go are configured to use -F/Library/Frameworks -framework MoltenVK and there's no good way to adjust the flags without creating a complete fork of the go libraries.

Having the option to create a standard MoltenVK.framework would make this much easier!

[billhollings]

Having the option to create a standard MoltenVK.framework would make this much easier!

Both .framework and .xcframework are effectively wrappers around a static library.

Are you able to simply link against the static library inside MoltenVK.xcframework? Or copy the static library to a .framework template?

[ptxmac]

Both .framework and .xcframework are effectively wrappers around a static library.

It's been a while since I had to dive deep into mac/ios development, but I believe framework's have always been dynamic libraries. The only reference I could find was this which is unfortunately quite old. (I did find references to ios starting out with only static frameworks, so clearly a bit of a mess)

the xcframework's seems to also support static libraries, but as mentioned these only work with xcode, and weirdly not clang

We changed vulkan-go to look for libraries in the system instead, but that means installing moltenvk is bit more manual. (and distribution would be harder)

[billhollings]

framework's have always been dynamic libraries

A .framework can contain both static and dynamic libraries. But the old MoltenVK .frameworks you're asking about contained static libraries. The MoltenVK.dylibs are delivered standalone.

We changed vulkan-go to look for libraries in the system instead

Does this mean you no longer need a separate MoltenVK.framework?

[ptxmac]

Does this mean you no longer need a separate MoltenVK.framework?

For this particular purpose, we found a workaround. See this note. It works, but only for local development. If I wanted to distribute applications using vulkan-go it would require a different approach.

Perhaps a better solution is to add make targets to just generate the static/dynamic libraries by themselves without the xcframework wrapper. It would be useful for non-xcode based projects. Of course, then things like search paths and linker flags need to be either provided by the user, or a pkg-config needs to be added to moltenvk

[billhollings]

generate the static/dynamic libraries by themselves

Both the static and dynamic libraries are already available in the package. The static libraries are inside the XCFramework, and the dynamic libraries are available standalone in the dylibs directory.

So...a few options...

We could copy the libMoltenVK.a files from inside the XCFramework to a set of standalone directories. That directory structure would literally be the same as the XCFramework but with maybe more user-friendly names? Or we could just symlink them from a similar directory structure. Or maybe just document that they are inside the XCFramework.

We could also do the same about creating .frameworks...copy the libMoltenVK.a files from inside the XCFramework into separate .framework templates.

[ptxmac]

Both solutions would cover my concerns. I think just having a documented way to use MolkenVK outside of XCode could be enough.

Another option would be simply installing the headers and libraries as any other non-framework library. I.e. copy copy the files to /usr/local/{include,libs} when the user runs make install-libs or something like that.

For context:

In vulkan-go the initial problem was that golang requires cflags and ldflags to be part of the source code. That means the library developer specifies how the linking will happen, and the library user has very few options to change it (I think rust have a similar setup).

In the case of vulkan-go the owner was kind enough to let me submit a patch that changed the linking flags. This patch adds the assumption that the user has manually copied the libraries manually to somewhere the compiler will find them. Similar changes are probably needed for the rust wrapper and other languages.

Basically, having a defined way to find the libraries would make it easier to maintain the wrapper libraries :)