Como migrar do Xcode para o Bazel

Informar um problema Mostrar fonte Por noite · 7,3 · 7,2 · 7,1 · 7,0 · 6,5

Nesta página, descrevemos como criar ou testar um projeto Xcode com o Bazel. Ela descreve as diferenças entre o Xcode e o Bazel e apresenta as etapas para converter um projeto Xcode em um projeto do Bazel. Ele também oferece e soluções de solução de problemas para lidar com erros comuns.

Diferenças entre o Xcode e o Bazel

  • O Bazel exige que você especifique explicitamente cada destino de build e os respectivos dependências, além das configurações de build correspondentes via regras de build.

  • O Bazel exige que todos os arquivos de que o projeto depende estejam presentes. no diretório do espaço de trabalho ou especificada como importações em WORKSPACE .

  • Ao criar projetos do Xcode com o Bazel, os arquivos BUILD se tornam o fonte de verdade. Se você trabalha no projeto no Xcode, é necessário gerar um nova versão do projeto Xcode que corresponde aos arquivos BUILD usando Tulsi sempre que você atualizar os arquivos BUILD. Se se não estiver usando o Xcode, os comandos bazel build e bazel test fornecem recursos de compilação e teste com algumas limitações descritas mais adiante neste guia.

  • Devido a diferenças nos esquemas de configuração do build, como layouts de diretório. ou flags de criação, o Xcode pode não ter uma visão completa do "quadro geral", da e, portanto, alguns recursos do Xcode podem não funcionar. São eles:

    • Dependendo dos destinos selecionados para conversão em Tulsi, o Xcode pode não consegue indexar corretamente a origem do projeto. Isso afeta o código e a navegação no Xcode, já que o Xcode não conseguirá ver todos do código-fonte do projeto.

    • A análise estática, os limpadores de endereços e os desinfetantes de linhas de execução podem não trabalho, já que o Bazel não produz as saídas que o Xcode espera esses recursos.

    • Se você gerar um projeto do Xcode com o Tulsi e usá-lo para executar os testes no Xcode, eles serão executados no Xcode, em vez de o Bazel Para executar testes com o Bazel, execute o comando bazel test manualmente.

Antes de começar

Antes de começar, faça o seguinte:

  1. Instale o Bazel se ainda não tiver feito isso.

  2. Se você não conhece o Bazel e os conceitos, faça o Tutorial do app iOS). Você já sabe que as ferramentas do Google Workspace, incluindo os arquivos WORKSPACE e BUILD, bem como o conceitos de destinos, regras de build e pacotes do Bazel.

  3. Analisar e entender as dependências do projeto.

Analisar as dependências do projeto

Ao contrário do Xcode, o Bazel exige que você declare explicitamente todas as dependências para para cada destino no arquivo BUILD.

Para mais informações sobre dependências externas, consulte Trabalhar com dependências externas.

Criar ou testar um projeto do Xcode com o Bazel

Para criar ou testar um projeto do Xcode com o Bazel, faça o seguinte:

  1. Criar o arquivo WORKSPACE

  2. (Experimental) Integrar dependências do CocoaPods

  3. Crie um arquivo BUILD:

    a. Adicionar o aplicativo de destino

    b. (Opcional) Adicionar os destinos do teste

    c. Adicionar destinos da biblioteca

  4. (Opcional) Granularizar o build

  5. Executar o build

  6. Gerar o projeto Xcode com o Tulsi

Etapa 1: criar o arquivo WORKSPACE

Crie um arquivo WORKSPACE em um novo diretório. Esse diretório se torna o arquivo do Bazel raiz do espaço de trabalho. Se o projeto não usa dependências externas, esse arquivo pode ser vazio. Se o projeto depender de arquivos ou pacotes que não estão em um dos nos diretórios do projeto, especifique estas dependências externas nos WORKSPACE .

Etapa 2: (experimental) integrar as dependências do CocoaPods

Para integrar dependências do CocoaPods no espaço de trabalho do Bazel, você precisa converter em pacotes do Bazel, conforme descrito em Como converter dependências do CocoaPods.

Etapa 3: criar um arquivo BUILD

Depois de definir o espaço de trabalho e as dependências externas, você precisa criar um arquivo BUILD que informe ao Bazel como o projeto está estruturado. Criar BUILD na raiz do espaço de trabalho do Bazel e configure-o para fazer build inicial do projeto da seguinte forma:

Dica:para saber mais sobre pacotes e outros conceitos do Bazel, consulte Espaços de trabalho, pacotes e destinos.

Etapa 3a: adicionar o aplicativo de destino

Adicionar um macos_application ou um ios_application destino da regra. Esse destino cria um pacote de aplicativos macOS ou iOS, respectivamente. No destino, especifique pelo menos o seguinte:

  • bundle_id: ID do pacote (caminho do DNS reverso seguido pelo nome do app) das binário.

  • provisioning_profile: perfil de provisionamento do seu desenvolvedor da Apple (ao criar para um dispositivo iOS).

  • families (somente iOS): se o aplicativo será criado para iPhone, iPad, ou ambos.

  • infoplists: lista de arquivos .plist a serem mesclados no arquivo Info.plist final.

  • minimum_os_version: a versão mínima do macOS ou iOS que o que o aplicativo suporta. Isso garante que o Bazel crie o aplicativo com a com os níveis corretos de API.

Etapa 3b: adicionar os destinos do teste (opcional)

Suporte às regras de build da Apple do Bazel testes de unidade baseados em biblioteca no iOS e macOS, além de testes de unidade de testes no macOS. Para testes baseados em aplicativos no iOS ou testes de interface no plataforma, o Bazel cria as saídas do teste, mas os testes precisam ser executados no Xcode por meio de um projeto gerado com Tulsi. Adicione destinos de teste da seguinte maneira:

  • macos_unit_test para executar testes de unidade baseados em biblioteca e aplicativo em um macOS.

  • ios_unit_test para executar testes de unidade baseados em biblioteca no iOS. Para testes que exigem o iOS simulador, o Bazel cria as saídas dos testes, mas não os executa. Você deve gerar um projeto Xcode com Tulsi e execute os testes no Xcode.

  • ios_ui_test para criar as saídas necessárias para executar testes de interface do usuário no simulador de iOS usando o Xcode. É necessário gerar um projeto Xcode com o Tulsi e execute os testes no Xcode. O Bazel não executa testes de interface nativamente.

Especifique no mínimo um valor para o atributo minimum_os_version. outros atributos de empacotamento, como bundle_identifier e infoplists; usar os valores mais usados como padrão, verifique se esses padrões são compatíveis com o projeto e ajustá-las conforme necessário. Para testes que exigem o iOS simulador, especifique também o nome de destino ios_application como o valor do test_host.

Etapa 3c: adicionar destinos da biblioteca

Adicionar um objc_library destino para cada biblioteca Objective C e um swift_library para cada biblioteca Swift da qual o aplicativo e/ou os testes dependem.

Adicione os destinos da biblioteca da seguinte maneira:

  • Adicionar os destinos da biblioteca do aplicativo como dependências de destino.

  • Adicione os destinos da biblioteca de teste como dependências aos destinos de teste.

  • Liste as origens de implementação no atributo srcs.

  • Liste os cabeçalhos no atributo hdrs.

.

Para saber mais sobre as regras de build, consulte Regras da Apple para o Bazel.

Neste ponto, é uma boa ideia testar o build:

bazel build //:<application_target>

Etapa 4 (opcional): detalhar o build

Se o projeto for grande ou conforme ele crescer, considere dividi-lo em vários pacotes do Bazel. Esse aumento de granularidade oferece:

  • Maior incrementabilidade de builds,

  • Maior carregamento em paralelo de tarefas de compilação,

  • Melhor capacidade de manutenção para futuros usuários

  • Melhor controle sobre a visibilidade do código-fonte entre destinos e pacotes. Isso evita o vazamento de problemas como bibliotecas que contêm detalhes de implementação em APIs públicas.

Dicas para granular o projeto:

  • colocar cada biblioteca no próprio pacote do Bazel. Comece com aqueles que exigem menos dependências e subir na árvore de dependências.

  • À medida que você adicionar arquivos BUILD e especificar destinos, adicione esses novos destinos ao deps atributos de destinos que dependem deles.

  • A função glob() não ultrapassa os limites dos pacotes, então, como o número de pacotes aumenta o número de arquivos correspondidos por glob() diminuem.

  • Ao adicionar um arquivo BUILD a um diretório main, adicione também um arquivo BUILD ao no diretório test correspondente.

  • Aplique limites de visibilidade íntegros nos pacotes.

  • Criar o projeto após cada grande mudança nos arquivos BUILD e corrigir erros de build à medida que você os encontra.

Etapa 5: executar o build

Execute o build totalmente migrado para garantir que ele seja concluído sem erros ou avisos. Execute todos os aplicativos e destinos de teste individualmente para encontrar origens com mais facilidade todos os erros ocorridos.

Exemplo:

bazel build //:my-target

Etapa 6: gerar o projeto Xcode com o Tulsi

Ao criar com o Bazel, os arquivos WORKSPACE e BUILD se tornam a origem. de verdade sobre o build. Para informar isso ao Xcode, gere um projeto Xcode compatível com Bazel usando Tulsi.

Solução de problemas

Erros do Bazel podem surgir quando ele fica dessincronizado com a versão selecionada do Xcode. como quando você aplica uma atualização. Confira o que você pode fazer se estiver Há erros no Xcode, por exemplo, "A versão do Xcode deve ser especificada para use uma CROSSTOOL da Apple".

  • Execute o Xcode manualmente e aceite os Termos e Condições.

  • Use Xcode select para indicar a versão correta, aceitar a licença e limpar o estado do Bazel.

  sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  sudo xcodebuild -license
  bazel sync --configure
  • Se isso não funcionar, tente executar bazel clean --expunge.
.