Em uma estrutura personalizada contendo código Objective-C e Swift , o compilador Swift gera o seguinte erro:
[build_path]/unextended-module.modulemap:2:19: error: umbrella header 'bugtest.h' not found
umbrella header "bugtest.h"
<unknown>:0: error: could not build Objective-C module 'bugtest'
— Tim Bodeit
Isso geralmente acontece após a renomeação de um projeto ou algo parecido. O problema é que o cabeçalho guarda-chuva não está mais listado como um cabeçalho Público . Verifique a imagem em anexo para ver como consertar isso.
Apenas uma observação para futuros leitores de que, para ver a seção 'Cabeçalhos' de 'Fases de construção', você precisa clicar em um destino de pod. O destino do aplicativo principal não listará uma seção 'Cabeçalhos'.
— shmim
Isso consertou totalmente. Obrigado. Esta deve ser a resposta aprovada.
Para mim - o nível de acesso era público, mas também falha no guarda-chuva não encontrado. Mudei a seção "Cabeçalhos" das "Fases de construção" para o topo e ela começou a funcionar.
— Aleksei Minaev de
Meu cabeçalho guarda-chuva já era público. Mover a seção para o topo também não ajudou.
Eu estava tendo um problema semelhante quando Carthage atualizou uma das minhas estruturas importadas. Acho que o XCode está tendo problemas para ficar de olho nas mudanças de caminho do framework referenciado. A reinicialização simples do XCode corrigiu o problema para mim.
No Xcode 7 Beta, com o Swift 2, isso também acontecerá se o cabeçalho do seu Framework não for declarado como "Público"
Por exemplo, eu tinha um Cocoa Touch Framework com uma visibilidade de "Projeto" para o arquivo de cabeçalho e o erro "Cabeçalho de guarda-chuva ... não encontrado" para todos os arquivos Swift em meu projeto, uma vez que tinha o cabeçalho "Público", o erro foi embora
— Claude Houle
No meu caso, quando encontrei esse problema, essa resposta parecia a resposta "mais correta" e funcionou para mim.
— greymouser
Eu concordo. Essa é a resposta correta. Verifique se o arquivo <projeto> .h tem a associação de destino e o nível de acesso corretos (público).
— user965972
@ Shadow_x99 como faço para definir o cabeçalho como "Público", minha pergunta está postada em stackoverflow.com/questions/36084291/…
— user2727195
Esta é na verdade uma variação da resposta de @arturgrigor, exceto que o Xcode realiza a mudança por conta própria. O resultado final deve ser o mesmo.
— original_username
Existem 4 maneiras diferentes de isso acontecer, ignorando bugs em versões anteriores do Xcode
Você não tem um cabeçalho abrangente chamado $ (TARGET_NAME) .h em seu projeto
Você tem um cabeçalho abrangente, mas não está definido como público. Veja a resposta de Arturgrigor
DEFINES_MODULE não está definido para YES
CLANG_ENABLE_MODULES não está definido para YES
— Claus Jørgensen
Uma 5ª causa que acabei de encontrar: o próprio umbrella_header.h não deve ser verificado em nenhum destino (assim como Info.plist)
Tenho tudo configurado corretamente nesta lista, mas ela falha.
Isso acontecerá quando a Always Search User Pathsconfiguração for habilitada para o destino do Framework.
Configurá-lo como Noresolverá esse erro.
IMHO, este é um bug no Compilador Swift e preenchi um radar com a Apple.
Veja rdar: // 21038443
Obrigado! Este é o que me pegou também.
Isso funcionou para mim. Um sintoma adicional é que ele falhou imediatamente após uma limpeza, mas teve êxito se você tentar novamente sem limpar.
Para mim - o nível de acesso era público, mas também falha no guarda-chuva não encontrado. Mudei a seção "Cabeçalhos" das "Fases de construção" para o topo e começou a funcionar. Script para podfile:
target.build_phases.each do |phase|
if (phase.display_name.include? phase_name)
target.build_phases.unshift(phase).uniq! unless target.build_phases.first == phase
Não tenho ideia do por que isso está acontecendo. Tentei em projetos fictícios - não está acontecendo. Apenas em grandes com várias dependências. Algo com a compilação ANTES de copiar os cabeçalhos guarda-chuva.
— Aleksei Minaev
Mover "Cabeçalhos" acima de "Fontes de compilação" funcionou para mim. xCode 8.2.1.
Mover a fase de cabeçalhos para o topo também funcionou para mim.
— Søren Mortensen
PodfileArquivo inválido : erro de sintaxe, fim de entrada inesperado, esperando keyword_end.
— Volodymyr Kulyk
Definitivamente, você deve definir sua estrutura como pública:
Funciona perfeitamente. Muito obrigado!
— kkiermasz
Qual é o contexto dessa captura de tela? O que você clica para chegar lá?
Para mim, definir 'Usar mapas de cabeçalhos' como 'NÃO' resolveu o problema
— xySVerma
… E no meu caso, defini-lo como SIM resolveu o problema. Infelizmente, não parece haver nenhuma documentação sobre essa configuração, mas sim é o padrão e não tenho certeza por que foi definido como não para um dos meus destinos.
Mais uma solução: depois de renomear uma pasta, o local antigo ainda pode estar listado no arquivo de projeto para o arquivo .h, mesmo se você atualizou o local por meio da barra lateral do Xcode. Este local antigo causa o erro de cabeçalho guarda-chuva.
Solução simples: Remova a referência ao arquivo .h e adicione novamente. (e lembre-se de torná-lo público novamente!)
— Danra
Descobri que, com o novo sistema Swift Build e Parallelize Build ativados, eu obteria erros como nesta pergunta. A solução foi vincular a estruturas que foram importadas nos arquivos de origem do swift. (Acho que anteriormente o aplicativo seria compilado porque simplesmente aconteceu que as estruturas estavam vinculadas a algo criado anteriormente na fila de compilação serial).
Eu escrevi um script para passar por todas as importações em todos os destinos em um espaço de trabalho e ter certeza de que suas estruturas foram vinculadas a esse destino.
https://github.com/Jon889/SwiftImportChecker
Já existem algumas respostas excelentes aqui. @ Shadow_x99 foi muito útil. No entanto, se eu pudesse complementar com minha própria experiência.
Um cabeçalho guarda-chuva é identificado automaticamente no processo de construção. Não é especificado nas configurações de construção do destino ou herdado das configurações do projeto.
Portanto, para evitar este erro que - a partir do XCode 7 - é o seguinte;
dois passos importantes devem ser dados.
Em primeiro lugar, o cabeçalho guarda-chuva deve ter o mesmo nome do destino . Portanto, se o seu destino for uma estrutura chamada MyTarget, deve haver um cabeçalho chamado MyTarget.h.
Em segundo lugar, nas fases de construção MyTarget- conforme mencionado na resposta - esse arquivo de cabeçalho deve ser listado na seção pública conforme detalhado acima.
Eu tive o mesmo problema e nenhuma das respostas sugeridas ajudou no meu caso, então estou deixando isso aqui para o caso de alguém ter o mesmo problema.
Eu tinha adicionado um "script de execução" em "fases de construção", mas acabei removendo-o e foi quando comecei a receber o erro.
Minha solução acabou tendo que limpar o projeto, reconstruir minha estrutura e então meu projeto de aplicativo construído corretamente.
— Ana figueira
Em minha experiência, você deve escolher nos alvos a estrutura que está causando o erro, não o alvo do projeto.
Em seguida, compile e, após compilar, estará disponível no destino do projeto.
Se você estiver usando o Xcode 7.1 e CocoaPods 0.39, parece haver uma mudança rápida no compilador que afeta alguns CocoaPods (Nimble, Quick, etc.) Experimente algumas das soluções especificadas neste tópico: https://github.com/ CocoaPods / CocoaPods / issues / 4420 entretanto, se nenhum deles funcionar, tente usar o Xcode 7.0.1 ou 7.2 beta. Você pode obter os dois aqui: https://developer.apple.com/downloads/ .
Edit: No meu caso, para corrigir o problema, também tive que fazer o downgrade do CocoaPods para 0.38.2.
Edição posterior: Parece não estar relacionado ao Xcode 7.1. Apenas fazer o downgrade do CocoaPods para 0.38.2 deve ajudar:
sudo gem uninstall cocoapods -v 0.39
sudo gem install cocoapods -v 0.38.2
Obrigado @Marius Ursache. Seguir suas instruções resolveu o problema para mim.
— Vick Swift
Seu arquivo de cabeçalho precisa estar na seção [Build Phases / Headers / Public].
Se o seu arquivo de cabeçalho já estiver na seção [Build Phases / Headers / Public], muitas vezes fazer o seguinte resolveu meu problema:
limpe o projeto
mova o arquivo de cabeçalho para a seção "privada" ou "projeto"
mova o arquivo de cabeçalho de volta para a seção "pública"
— Andrei A.
Uau, essa é a única que funcionou nessas dezenas de respostas e parece que seria a menos provável, obrigado!
Resolvi isso renomeando meu module.modulemap para moduleXYZ.modulemap e alterando o nome do arquivo modulemap nas configurações do projeto
— retterdesapok
No meu caso, acabei de construir a estrutura específica com seu esquema. E então reconstruir todo o projeto e resolver o problema
— Hudi Ilfeld
Remova esses arquivos do diretório do projeto. .xcworkspace pods/epodfile.lock
atualize o pod e construa o projeto.
Eu corrigi-lo tornando o modo de compilação das configurações de compilação do framework problemático para incremental.
— Ghislain Leblanc
No meu caso, o problema foi causado pelo script de remoção de cabeçalhos nas fases de construção
function removeHeaders() {
find $BUILD_ROOT/...  -name '*.h' -exec rm -f {} \;
Excluir esse script corrigiu o problema.
— phnmnn
Nenhuma das 9 respostas me ajudou, então tentei criar um novo projeto que pudesse enviar à Apple para registrar um bug. Fiquei surpreso por não conseguir reproduzir o problema. Verifiquei as configurações de compilação e elas eram equivalentes. Aparentemente, é algum tipo de bug.
Se nada mais ajudar , tente criar um novo projeto e importar pelo menos algumas classes Objective C e Swift do seu projeto atual, compare as configurações de construção relacionadas ao framework com os valores padrão do novo projeto e, eventualmente, mova todos os arquivos para o novo projeto.
Estou trabalhando nisso há um dia inteiro, mas vale a pena. Tentei de todas as maneiras aqui, mas não resolvi. Eu criei um novo projeto, um experimento, e descobri que o caminho de pesquisa do cabeçalho do usuário foi definido como $ {SRCROOT} recursivo e mudei para $ {SRCROOT} não recursivo , mudei o caminho do cabeçalho de ponte (por exemplo #import "SVProgressHUD.h" -> #import "Pods/SVProgressHUD/SVProgressHUD/SVProgressHUD.h"), o o erro foi embora.