-config.cmake` in `lib/cmake/pkgname`.
---
### Author:  [@a4z](https://discourse.cmake.org/u/a4z)
#### Post date: [September 20, 2024, 7:07am UTC](https://discourse.cmake.org/t/best-way-to-consum-a-binary-xcframework-zip/11721/5 "2024-09-20T07:07:49Z")
Thanks for the info! The ‘problem’ is that the xcframework creation does not happen via CMake,
so there is logically no install step.
With CMake you create the frameworks, or just libraries, for the target platforms, one by one.
And then use xcodebuild to put them together into the multi platform xcframework.
Therefore, the workflow is a bit different from the usual way.
Also, getting the xcframework. Is is most likely a binary distribution because the idea is for binary distributions, and the easiest way to get that is by using the file functions for downloading and unpacking.
Will continue looking into that, but it would be nice if cmake’s `find_package` would understand a folder with some xcframework folder in it as a package source, because a XCFramewrok is a package by definition 😉
And this would keep the interface for the user consistent, because atm I would have to say, Mac, you get a XCFramework, use find\_library. Other platforms, for which we also do binary distributions, those can be found with find\_package. But I have to look into this a bit more, this whole topic is not trivial.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 20, 2024, 11:36pm UTC](https://discourse.cmake.org/t/best-way-to-consum-a-binary-xcframework-zip/11721/6 "2024-09-20T23:36:39Z")
> [@a4z](#):
>
> …because a XCFramewrok is a package by definition
It isn’t a package by CMake’s definition. It doesn’t provide any CMake target information, transitive properties, etc. I would still recommend wrapping it in a proper CMake package rather than distributing it as a raw XCFramework if you want it to be easy for projects to consume.
> [@a4z](#):
>
> …this whole topic is not trivial.
This is frequently true of packaging, especially so if you need to distribute cross-platform, and ludicrously so if the platforms include Apple. 😬
---
### Author:  [@a4z](https://discourse.cmake.org/u/a4z)
#### Post date: [September 21, 2024, 7:16am UTC](https://discourse.cmake.org/t/best-way-to-consum-a-binary-xcframework-zip/11721/7 "2024-09-21T07:16:22Z")
I started to develop the idea that (something like) XCFrameworks + [CPS files](https://cps-org.github.io/cps/) might be a viable way to proceed with the ecosystem evolution question.
I agree that the Apple platform is sometimes a bit special, but it also solves some things elegantly or pragmatically.
Btw, I am amazed the CMake was able to figure out the include paths for the XCFramework magically. That is something XCode seems to fail with (probably because its all about Swift now).
But I also wonder about the rules CMake follows. Yesterday, I thought, if I have the same module definition and includes for all platforms, why not have just 1 include folder on the top level instead of one for each architecture/platform?
Is there a location I could look up how cmake resolves that?
I found some logic in cmComputeLinkInformation.cxx, but could not run the code in my head
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [September 21, 2024, 7:20am UTC](https://discourse.cmake.org/t/best-way-to-consum-a-binary-xcframework-zip/11721/8 "2024-09-21T07:20:10Z")
> [@a4z](#):
>
> why not have just 1 include folder on the top level instead of one for each architecture/platform?
Frameworks are not required to provide the same headers across all platforms. It would be quite likely that some frameworks will want different variants of the same headers, or even different headers that should only be present for a subset of platforms. Each framework within an `.xcframework` needs to be fully self-contained. Think of an `.xcframework` as essentially just a collection of platform-specific frameworks that the build system knows how to find and use the specific one it needs.
---
### Author:  [@a4z](https://discourse.cmake.org/u/a4z)
#### Post date: [September 21, 2024, 7:30am UTC](https://discourse.cmake.org/t/best-way-to-consum-a-binary-xcframework-zip/11721/9 "2024-09-21T07:30:54Z")
yes, I know, but a xcframework can also be just a collection of libraries, not frameworks
and `xcodebuild -create-xcframework` does not require me to specify some include directory if I give it a bunch of libs. And the plist file has a headers section, so in theory … (and now writing this, I wounder why XCode does not find that)
if it would be the same, it would be nice to avoid redundancy, but it’s also not important
anyhow, nice topic, learned a lot, thanks for your support, Craig!