Ancestors

Written by Rob Napier on 2025-01-30 at 23:18

I'm a bit confused why some most frameworks in SPM build as X.framework, but a few build as X__PackageProduct.framework.

I have one of those, and it seems to be linking twice in my unit tests, leading to two copies of a static variable.

I'm certain I have two copies of a static variable, but I'm not yet certain it's related to the "PackageProduct."

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-01-31 at 02:56

My current suspicion is it’s related to how I’m importing things. A imports B. The app imports both A and B. The tests import A.

The B the app sees is different than the B the tests see.

I might be able to figure out the right Package config, but just moving B into A also seems to fix it, and that’s not bad in this case.

I’m not sure how much it would take to make an example project. The fact that there are two repositories might matter. I’ll see.

But I wish I knew what PackageProduct meant.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-01-31 at 22:27

I am pretty sure I’ve figured it out. The test target for hosted Xcode tests is a plugin. If you have a test target that depends on things that your app also depends on, the test target will get its own copy of the frameworks. That will lead to collisions that will mostly work, but can lead to duplicate statics for example.

Currently I’m exploring how to remove that dependency. It breaks the test’s build of course. I’m exploring wrapping the shared code in a “if canImport” which might work.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-02-03 at 00:40

Continuing this exploration.

I key thing I believe to watch out for is any Frameworks showing up in an xctest bundle. This is very likely to cause a collision. I'm considering writing a tool to watch for this case.

The root is a testing support framework that itself relies on shipping frameworks. The solution so far is to remove the dependencies from the test support framework, and add an #if canImport wrapper on the test support code so it only works when linked with something else.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Written by Rob Napier on 2025-02-03 at 00:44

I don't think this is quite a final solution. It seems to work and there's a certain "weak linking" aspect to it. But it's hard to see when it will be a problem. I have another test support framework where this doesn't happen. I have some feelings about why (I think maybe being in a monorepo vs across multiple repos matters; but it might just be the number of dependency layers), but not enough to convince me I'm missing a simpler answer. I haven't been able to easily repro it in a smaller repo.

=> More informations about this toot | More toots from cocoaphony@mastodon.social

Toot

Written by Duncan Babbage on 2025-02-03 at 09:57

@cocoaphony this would be a good Apple Technical Support Incident, if like me you often don’t use them most years? Get an answer straight from the team, potentially?

=> More informations about this toot | More toots from babbage@iosdev.space

Descendants