Hi,
On Mon, Jul 1, 2019 at 12:55 PM nobrien via WebP Discussion
<webp-d...@webmproject.org> wrote:
>
> Building an iOS app for Mac with Apple's macOS 10.15 Catalina technology, Project Catalyst, results in failure to link the WebP.framework.
>
What's the failure out of curiosity?
error: Building for UIKit for Mac, but the linked framework 'WebP.framework' was built for <unknown>. You may need to restrict the platforms for which this framework should be linked in the target editor, or replace it with an XCFramework that supports both platforms. (in target 'Sample App')
> Will likely need to rebuild WebP.framework with Xcode 11 (currently in beta).
>
> Would it be possible to get a drop of WebP.framework built to support iOS apps on Mac? And to update the iosbuild.sh script?
>
If you have the beta installed it might be easier to rebuild libwebp
from the 1.0.2 branch using the iosbuild.sh script locally, it doesn't
have much in the way of dependencies (which can be satisfied using
homebrew/ports). We'll be making a 1.0.3 release soon, but in general
we use the latest stable version of the tools for the binary archives.
Hi,
On Wed, Apr 29, 2020 at 10:14 AM <ben.sp...@driveclutch.com> wrote:
>
> It's been a year, Xcode 11 is no longer beta. I get the same build failures. Are there any updates on this?
>
Thanks for bumping the thread. The framework released with 1.1.0 was
built using Xcode 11.0. Are you running into the issue using that
framework or one built locally using iosbuild.sh?
If you have instructions on how to reproduce the issue I can try it out locally.
> --
> You received this message because you are subscribed to the Google Groups "WebP Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to webp-d...@webmproject.org.
Hey guys any luck with this?
To unsubscribe from this group and stop receiving emails from it, send an email to webp-discuss...@webmproject.org.
To view this discussion on the web visit https://groups.google.com/a/webmproject.org/d/msgid/webp-discuss/da188d08-c450-4aa8-b06f-cb8d2413f06bn%40webmproject.org.
We're now hoping to get a drop of this as well, the integration we had before to just build the raw code for Catalyst no longer works when building for Apple Silicon (using the Apple Silicon DTK).On Monday, July 20, 2020 at 1:13:10 PM UTC-7 James Zern wrote:On Mon, Jul 20, 2020 at 12:45 PM Cem Kozinoglu <c...@thecatch.app> wrote:Hey guys any luck with this?Sorry for the lack of reply on this one. I was working with a mac remotely that I lost access to so I haven't had a chance to take a look at the behavior. When I get that resolved I'll take a look and see if I can address the issue in time for our next release.
error: Multiple commands produce '.../Build/Products/Debug-iphoneos/include/demux.h':
1) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebP.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios
2) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebPDemux.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios
The problem comes because the Headers directory in the xcframework for each version of the library includes files with the same name. When Xcode copies them into the includes directory, they conflict and the build fails. The suggested fix in the thread was to nest the headers in uniquely named directories within the Headers directory and after doing that, it works.
So in the WebP.xcframework, I move the headers from WebP.xcframework/{platform-archs}/Headers/decode.h to WebP.xcframework/{platform-archs}/Headers/WebP/decode.h and then I am able to import them in Objective C using #import <WebP/decode.h> just like we were doing with WebP.framework in the past.
Now I must admit that I'm not too familiar with xcframeworks and I have no idea if this is the approach that we must take, but I do know that its required in order to use multiple xcframeworks with headers that are named the same. Do you have any thoughts on this?
There is a bit more context here: https://github.com/twitter/ios-twitter-image-pipeline/pull/66
Thanks for the work so far!
Liam
Hi Everbody!Thanks James for adding xcframework support, I was able to get this working in Twitter Image Pipeline but I had to make a little tweak to work around an issue that I ran into however it's not immediately clear to me where the issue lies and if its something we can fix (or need to fix?) here.
The issue that i hit was similar to what is described in this thread: https://developer.apple.com/forums/thread/651043When I include both WebP.xcframework and WebPDemux.xcframework in a project and add link it to a target, i get errors like the following:error: Multiple commands produce '.../Build/Products/Debug-iphoneos/include/demux.h':
1) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebP.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios
2) Command: ProcessXCFramework .../ios-twitter-image-pipeline/Extended/WebPDemux.xcframework .../Build/Products/Debug-iphoneos/include/decode.h ios
The problem comes because the Headers directory in the xcframework for each version of the library includes files with the same name. When Xcode copies them into the includes directory, they conflict and the build fails. The suggested fix in the thread was to nest the headers in uniquely named directories within the Headers directory and after doing that, it works.
So in the WebP.xcframework, I move the headers from WebP.xcframework/{platform-archs}/Headers/decode.h to WebP.xcframework/{platform-archs}/Headers/WebP/decode.h and then I am able to import them in Objective C using #import <WebP/decode.h> just like we were doing with WebP.framework in the past.
Now I must admit that I'm not too familiar with xcframeworks and I have no idea if this is the approach that we must take, but I do know that its required in order to use multiple xcframeworks with headers that are named the same. Do you have any thoughts on this?