O iOS Xcode SPM não conseguiu desmontar a superclasse


9

Meu aplicativo é composto de muitos projetos (estruturas), um para cada recurso principal e um quadro comum com todos os tipos de coisas que eu preciso acessar em vários dos meus recursos.

Estou usando o Swift Package Manager do Xcode 11 para adicionar dependências.

A estrutura comum contém uma dependência do RxSwift, que eu uso durante todo o projeto.

Estou enfrentando problemas quando tento usar o RxTest em qualquer uma das minhas estruturas de recursos.

Se eu adicionar o RxTest via SPM diretamente ao destino do teste e executar os testes, recebo

falha ao desmontar a superclasse de 'nome da classe' do nome mutilado 'outro nome da classe'

e muitos

A classe 'nome da classe' é implementada tanto no 'caminho da estrutura comum' quanto no 'caminho de destino do teste'

onde todas essas classes estão relacionadas à Rx. O erro 'falha ao desmembrar' falha no teste e só ocorre quando tento inicializar uma classe RxTest.

Se eu adicionar o RxTest à estrutura comum, os testes executam bem, mas quando executo o aplicativo, recebo

dyld: Biblioteca não carregada: @ rpath / XCTest.framework / XCTest

O que faz sentido, porque estou adicionando uma estrutura de teste a uma estrutura que não é de teste e não é algo bom de se fazer.

Então, basicamente, não consegui obter uma configuração em que os testes e o aplicativo funcionem bem. O aplicativo é executado ou os testes são executados.

Como posso fazer isso funcionar? Existe uma maneira de incluir o RxTest na estrutura comum somente quando eu o construo em um destino de teste? Ou o RxTest deve ser incluído apenas nos destinos de teste e estou faltando alguma configuração?

Respostas:


2

O Xcode com dependências do SPM não pode lidar com a mesma dependência do SPM em vários destinos que são dependentes um do outro no momento. Cada dependência precisa estar apenas em um único destino no momento. Não sei por que, a partir de agora, mas tentarei investigar mais e arquivar o bug se ainda não estiver arquivado.


Olá, alguma sorte em descobrir mais?
janh

Encontrou algo sobre isso?
bogen 31/01

Nada até agora :) A questão realmente é: vincula estaticamente as dependências nos destinos.
Zdeněk Topič 17/02

0

É provável que seu problema seja que a biblioteca esteja usando vinculação estática em vez de vinculação dinâmica. No SwiftPM, você pode especificar uma biblioteca como estática ou dinâmica, se desejar, ou pode deixar o sistema de compilação decidir qual é o que a maioria dos pacotes faz. O Xcode parece favorecer a abordagem estática ao compilar com o SwiftPM, o que resulta nos problemas de compilação que você está enfrentando.

Se você modificar o Package.swiftter RxTestser uma biblioteca dinâmica em vez disso, deve funcionar. Você pode testar isso facilmente, clonando RxSwifte modificando esta linha:

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

para dentro:

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

e, em seguida, arrastando a cópia local de RxSwift para o seu Xcode Project Navigator. Ele usará sua cópia local do pacote em vez da cópia clonada pelo Xcode.

Depois de fazer isso, você pode vinculá-lo a qualquer destino que você precisa e deve funcionar. Se isso realmente resolver o problema, é provável que suas soluções de longo prazo:

1) Tenha um fork que simplesmente o altere para uma biblioteca dinâmica.

2) Convença a RxSwiftcomunidade a alterar seus produtos para versões dinâmicas ou de venda dinâmica, além do padrão.

3) Não use RxTestcoisas semelhantes em vários lugares.


Também é importante notar que o Xcode 11.3 e versões anteriores não suportam arquivamento com pacotes Swift dinâmicos. Portanto, se você seguir a rota dinâmica, terá que esperar pelo Xcode 11.4.


Clonar e modificar cada dependência não me parece uma solução. A maioria dos pacotes está usando o tipo padrão, o que é um pouco automático, acredito e escolhe o link estático toda vez, por algum motivo. Eu esperaria que, uma vez que o pacote esteja vinculado em vários destinos, ele escolheria vinculá-lo dinamicamente.
Zdeněk Topič 17/02

Ya é uma dor. Concordo que a dinâmica seria o comportamento esperado aqui. O melhor que podemos fazer para alterar isso é enviar uma solicitação de feedback à Apple.
bscothern 17/02
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.