Como migrar do Xcode para o Bazel

Informar um problema Ver código-fonte Nightly · 7.4 . 7,3 · 7.2 · 7,1 · 7,0 · 6,5

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

Diferenças entre Xcode e 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ê trabalhar no projeto no Xcode, será necessário gerar uma nova versão do projeto do Xcode que corresponda aos arquivos BUILD usando rules_xcodeproj sempre que você atualizar os arquivos BUILD. Certas mudanças nos arquivos BUILD como adicionar dependências a um destino, não exigem a regeneração do em um projeto, o que pode acelerar o desenvolvimento. Se você não estiver usando o Xcode, os comandos bazel build e bazel test oferecem recursos de build e teste com algumas limitações descritas mais adiante neste guia.

Antes de começar

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

1. Instale o Bazel, caso ainda não tenha feito isso.

2. Se você não conhece o Bazel e os conceitos dele, conclua o tutorial do app iOS. Você já sabe que as ferramentas do projeto, incluindo os arquivos WORKSPACE e BUILD, assim como o conceitos de destinos, regras de build e pacotes do Bazel.

3. Analise e entenda 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 de 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 SwiftPM

3. Crie um arquivo BUILD:

   a. Adicionar o destino do aplicativo

   b. (Opcional) Adicionar os destinos de teste

   c. Adicionar destinos da biblioteca

4. (Opcional) Granularizar o build

5. Executar o build

6. Gere o projeto Xcode com rules_xcodeproj

Etapa 1: criar o arquivo WORKSPACE

Crie um arquivo WORKSPACE em um novo diretório. Esse diretório se torna a raiz do espaço de trabalho do Bazel. 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 diretórios do projeto, especifique essas dependências externas no arquivo WORKSPACE.

Observação: coloque o código-fonte do projeto na árvore de diretórios que contém o arquivo WORKSPACE.

Etapa 2: (experimental) integrar dependências do SwiftPM

Para integrar as dependências do SwiftPM ao espaço de trabalho do Bazel com swift_bazel, faça o seguinte: é preciso convertê-los em pacotes do Bazel, conforme descrito neste tutorial.

Observação: o suporte ao SwiftPM é um processo manual com muitas variáveis. A integração do SwiftPM com o Bazel não foi totalmente verificada e não foi com suporte oficial.

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. Crie o arquivo BUILD na raiz do espaço de trabalho do Bazel e configure-o para fazer um build inicial do projeto da seguinte maneira:

• Etapa 3a: adicionar o destino do aplicativo
• Etapa 3b: adicionar os destinos de teste (opcional)
• Etapa 3c: adicionar destinos da biblioteca

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

Etapa 3a: adicionar o destino do aplicativo

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

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

• provisioning_profile: perfil de provisionamento da sua conta de desenvolvedor da Apple (se estiver criando 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 os níveis de API corretos.

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 em qualquer plataforma, o Bazel vai criar as saídas de teste, mas os testes precisam ser executados no Xcode por um projeto gerado com rules_xcodeproj. 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. É necessário gerar um projeto do Xcode com rules_xcodeproj e executar os testes no Xcode.

• ios_ui_test para criar saídas necessárias para executar testes de interface do usuário no simulador do iOS usando o Xcode. Você precisa gerar um projeto Xcode com rules_xcodeproj e execute os testes no Xcode. O Bazel não pode executar testes de IU de forma nativa.

Especifique pelo menos um valor para o atributo minimum_os_version. outros atributos de empacotamento, como bundle_identifier e infoplists; usar como padrão os valores mais usados, garanta que esses padrões sejam 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

Adicione um destino objc_library para cada biblioteca Objective-C e um destino swift_library para cada biblioteca Swift de que o aplicativo e/ou os testes dependem.

Adicione os destinos da biblioteca da seguinte maneira:

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

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

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

• Liste os cabeçalhos no atributo hdrs.

Observação: é possível usar a função glob para incluir todas as origens e/ou cabeçalhos de um determinado tipo. Usar com cuidado, porque ela pode incluir arquivos que você não quer que o Bazel crie.

Você pode procurar exemplos existentes de diversos tipos de aplicativos diretamente na Diretório de exemplos derules_apple. Exemplo:

• Alvos de aplicativos do macOS

• Destinos de aplicativos iOS

• Aplicativos multiplataforma (macOS, iOS, watchOS, tvOS)

Para mais informações 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) Granular 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:

• Aumento da incrementalidade dos builds,

• Aumento da paralelização de tarefas de build.

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

• Controle melhor da visibilidade do código-fonte em destinos e pacotes. Isso evita problemas como bibliotecas que contêm detalhes de implementação vazados para APIs públicas.

Dicas para granular o projeto:

• Coloque cada biblioteca no próprio pacote do Bazel. Comece com os que exigem o menor número de dependências e avance pela á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() diminuirá.

• 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 saudáveis nos pacotes.

• Crie o projeto após cada mudança importante nos arquivos BUILD e corrija os erros de build conforme eles aparecem.

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 rules_xcodeproj

Ao criar com o Bazel, os arquivos WORKSPACE e BUILD se tornam a fonte de informações sobre o build. Para informar isso ao Xcode, gere uma Projeto Xcode compatível com Bazel usando rules_xcodeproj.

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 algumas soluções se você estiver enfrentando erros com o Xcode, por exemplo, "A versão do Xcode precisa ser especificada para usar um CROSSTOOL da Apple".

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

• Use o 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.

Observação: se você salvou o Xcode em um caminho diferente, use xcode-select -s para apontar para esse caminho.