SPOS iOS Xcode SPM не вдалося демантувати надклас


9

Мій додаток складається з безлічі проектів (фреймворків), по одному для кожної основної функції та загальної рамки зі всілякими речами, до яких мені потрібно отримати доступ у кількох своїх функціях.

Я використовую Swift Package Manager Xcode 11 для додавання залежностей.

Загальна основа містить залежність RxSwift, яку я використовую протягом усього проекту.

Я стикаюся з проблемами, коли намагаюся використовувати RxTest в будь-якій моїй функції.

Якщо я додаю RxTest через SPM до тестової цілі безпосередньо та проведу тести, я отримаю

не вдалося демантувати надклас "ім'я класу" від невідомого імені "інше ім'я класу"

і багато

Клас "ім'я класу" реалізовано як у "загальному контурному шляху", так і в "тестовому цільовому шляху"

де всі ці класи пов'язані з Rx. Помилка 'не вдалося демангувати' руйнує тест і виникає лише тоді, коли я намагаюся ініціалізувати клас RxTest.

Якщо я додати RxTest до загальної основи, тести працюють нормально, але коли я запускаю програму, я отримую

dyld: Бібліотека не завантажена: @ rpath / XCTest.framework / XCTest

Що має сенс, тому що я додаю тестовий фреймворк до нетестової системи, і це не щось добре робити.

Таким чином, я не зміг отримати конфігурацію, коли і тести, і додаток працюють нормально. Або запуск програми, або тести.

Як я можу це налагодити? Чи є спосіб включити RxTest до загальної основи лише тоді, коли я будую його на тестовій цілі? Або RxTest повинен бути включений лише до тестових цілей, і мені не вистачає певної конфігурації?

Відповіді:


2

Xcode із залежностями SPM не може впоратися з однаковою залежністю SPM у кількох цілях, які залежать одна від одної. Кожна залежність на даний момент повинна бути лише в одній цілі. Я не знаю, чому станом на даний момент, але я спробую розглянути більше і подати помилку, якщо вона ще не подана.


Привіт, будь-яка удача дізнатися більше?
січень

Знайшли щось про це?
bogen

Нічого поки що :) Питання насправді полягає в тому, що він стаціонально пов’язує залежності в цілях.
Zdeněk Topič

0

Ваша проблема, ймовірно, у бібліотеці використовується статичне посилання замість динамічного посилання. У SwiftPM ви можете вказати бібліотеку як статичну або динамічну, якщо ви хочете, або ви можете просто дозволити системі збирання вирішувати, що саме робить більшість пакунків. Здається, що Xcode надає перевагу статичному підходу, коли він будується за допомогою SwiftPM, що спричиняє проблеми зі збиранням.

Якщо ви модифікуєте Package.swift, RxTestматимете динамічну бібліотеку, вона повинна працювати. Ви можете легко перевірити це, клонувавши RxSwiftта змінивши цей рядок:

.library(name: "RxTest", targets: ["RxTest"]),

в:

.library(name: "RxTest", type: .dynamic, targets: ["RxTest"]),

а потім перетягніть локальну копію RxSwiftу свій навігатор Xcode Project. Потім він використовуватиме вашу локальну копію пакету замість клонованої Xcode.

Після цього ви зможете зв’язати це з будь-якими потрібними цілями, і це повинно працювати. Якщо це насправді вирішує проблему, то, ймовірно, ваші довгострокові рішення:

1) Майте вилку, яка просто змінює її на динамічну бібліотеку.

2) Переконайте RxSwiftспільноту змінити свої продукти на динамічні або продати динамічні версії на додаток до стандартних.

3) Не використовуйте RxTestабо подібні речі в декількох місцях.


Варто також зазначити, що Xcode 11.3 і новіші версії не підтримують архівування за допомогою динамічних пакетів Swift. Тож якщо ви спуститеся по динамічному маршруту, вам доведеться чекати Xcode 11.4.


Клонування та зміна кожної залежності не здається вирішенням для мене. Більшість пакунків використовують тип за замовчуванням, який є дещо автоматичним, я вважаю, і обирає статичне посилання кожного разу з якихось причин. Я б очікував, що оскільки пакет пов'язаний у декількох цілях, він вирішить динамічно пов'язати його.
Zdeněk Topič

Так, це біль. Я погоджуюсь, що тут динамічною буде очікувана поведінка. Найкраще, що ми можемо зробити, щоб змінити, це подати запит на зворотний зв'язок з Apple.
бсковер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.