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
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
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
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
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
@cocoaphony I cannot stand how SPM interacts with the Xcode build system. There’s so much implicit behavior.
=> More informations about this toot | More toots from mattiem@mastodon.social
@cocoaphony idk if this is possible in a SPM-only setup, but in an xcodeproj this kind of situation can be avoided for unit tests by removing the app as being the TEST_HOST builds setting for the test app. [1/3]
=> More informations about this toot | More toots from aligatr@ohai.social
@cocoaphony If you do that you'll have to add all the source files of the app target that your unit test requires (models, SUTs…) to the test target too of course (or move those common files to a shared framework linked by each), but at least your test target won't be loaded as a plugin to your app target by the test harness anymore, removing the double-loading of symbols. [2/3]
=> More informations about this toot | More toots from aligatr@ohai.social
@cocoaphony Of course this is not applicable to UI Tests, which do need to be loaded as plugins into the app binary for them to be able to control the app's UI from within, so it's not always that simple.
Also, I am not sure why Apple makes the app target be the TEST_HOST of newly-created test targets by default (I think), as to me it'd be better conceptually to make Unit Tests targets independent of app's UI code and only link to models under test… 🤷 [3/3]
=> More informations about this toot | More toots from aligatr@ohai.social
@aligatr @cocoaphony I’m a big advocate for not using hosted tests and for the app target being almost as lean as a single main.swift (when possible).
=> More informations about this toot | More toots from orj@mastodon.social
@aligatr @cocoaphony for the record: UITests are not loaded as a plugin into the app binary to control the app’s UI. They run as a completely separate process and interact through Accessability API’s. They are fully out of process.
=> More informations about this toot | More toots from monocularvision@mastodon.social
@monocularvision @cocoaphony Ah, indeed, thanks for the correction 👍
=> More informations about this toot | More toots from aligatr@ohai.social
@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
@cocoaphony It’d be interesting to have a subtool of swiftpm that can show you the mastering rules for the targets making up a product. Like, “tell me where you’d put this if you built it and why”
=> More informations about this toot | More toots from cfi@mastodon.social
@cfi @cocoaphony ooohhh, yes please! This would be very good for tying in to other build systems, too
=> More informations about this toot | More toots from dgregor79@sfba.social This content has been proxied by September (3851b).Proxy Information
text/gemini