xcframework contents are copied into bin

[roymacdonald]

on macos, since the core addons' libraries are now xcframeworks, the contents of these are being copied to the projects bin folder. This is not necesary and should not happen.
@dimitre @danoli3

[danoli3]

its copying to the temp folder which is also the bin folder, I had a solution for this at one point, was something to do with changing the cache dir

[roymacdonald]

but it is not deleting these, actually, the headers and .a files dont need to be copied anywhere.

So I don't get why it is done , not sure either if it is something misconfigured on our side or if it is the xcframework default behaviour.

[dimitre]

duplicate of #8063

[roymacdonald]

I also noticed that all the core static libraries are getting copied into libs/openFrameworksCompiled/lib/macos which I think there is no need for those to sit there.

But then, when using any addon that has a static libraries, its files get copied into the app bundle next to the executable, which unnecessarily bloats the app file size. It is quite noticeable when using opencv for example.

Honestly, I dont see what is the gain on having xcframeworks instead of what we had. I get the idea for developing ios/etc, but for macos it does not make sense to much at least at the current state. I see no benefits from it. Please let me know what are the reasons or need to have xcframeworks instead of what we used to have.

[danoli3]

This is happening regardless of xcframeworks or .a binding or libs, it’s a thing with temp static location shouldn’t be an issue once we just set the path correct. Normally this is placed in the project temp location which can be cleared by following the settings in project, however it’s misconfigured currently using bin. xcframeworks is not just about multi platform, it’s a structure of definitions, versions, build settings and allows for multi platform. It’s the same as a .app is really a folder of libraries, executables and signing info. It’s the structure Apple have defined for libraries going forward. Again just open it it’s still a folder of the static a. This week guys! I’ll fix it all

…

On Thu, 17 Oct 2024 at 2:33 pm, Roy Macdonald ***@***.***> wrote: I also noticed that all the core static libraries are getting copied into libs/openFrameworksCompiled/lib/macos which I think there is no need for those to sit there. But then, when using any addon that has a static libraries, its files get copied into the app bundle next to the executable, which unnecessarily bloats the app file size. It is quite noticeable when using opencv for example. Honestly, I dont see what is the gain on having xcframeworks instead of what we had. I get the idea for developing ios/etc, but for macos it does not make sense to much at least at the current state. I see no benefits from it. Please let me know what are the reasons or need to have xcframeworks instead of what we used to have. — Reply to this email directly, view it on GitHub <#8147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HAGWZ6VICKSTGJYQJ3Z34VZVAVCNFSM6AAAAABQAM4W2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJYGQZDKNJTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[danoli3]

Yeah misconfiguration of projectGenerator it seems. Manually adding to LDFlags causing this

[danoli3]

Yeah this is all due to misconfiguration of

[CONFIGURATION](https://developer.apple.com/documentation/xcode/build-settings-reference#CONFIGURATION)
Setting name: CONFIGURATION
Identifies the build configuration, such as Debug or Release, that the target uses to generate the product.
[Per-configuration Build Products Path](https://developer.apple.com/documentation/xcode/build-settings-reference#Per-configuration-Build-Products-Path)
Setting name: CONFIGURATION_BUILD_DIR
The base path where build products will be placed during a build for a given configuration. By default, this is set to $(BUILD_DIR)/$(CONFIGURATION).
[Per-configuration Intermediate Build Files Path](https://developer.apple.com/documentation/xcode/build-settings-reference#Per-configuration-Intermediate-Build-Files-Path)
Setting name: CONFIGURATION_TEMP_DIR
The base path where intermediates will be placed during a build for a given configuration. By default, this is set to $(PROJECT_TEMP_DIR)/$(CONFIGURATION).

instead of using BUILD_PRODUCTS_DIR

[ofTheo]

This is still an issue and the behavior happens regardless of where we are building to.

It seems that the default behavior is to copy the contents of include and the libraries to the CONFIGURATION_BUILD_DIR folder ( I am guessing so they can be linked for the architecture, but god knows why they aren't just linked from their current location ).

Anyway this seems to be a downside of XCFrameworks.
For most people they won't notice that's its copying the .a's over as its doing so inside of their DerrivedData folder, eg:

But in our case our build folder is bin/ so this means we get all these .a's copied over for each project.

Working Solution:
For OS X builds we need to not add the XCFramework to the final project, but just add the static lib inside of it to the other linker flags. This will be a PG fix.