Oito armadilhas ao compilar AdvPL e TLPP fora do TDS

O terminal terminou sem uma mensagem assustadora. Isso basta para afirmar que a alteração está disponível no Protheus? Ainda faltam algumas perguntas: qual ação executou, contra qual ambiente, sobre quais arquivos e com qual resultado final?

Automatizar a compilação reduz trabalho repetitivo, mas também permite repetir um erro rapidamente. Estas oito armadilhas ajudam a organizar uma conferência que começa antes do comando e termina depois da leitura do log. O procedimento completo, do arquivo de ações ao teste funcional, está em Compilar AdvPL e TLPP pela linha de comando.

1. Tratar o RPO como se fosse a pasta local do projeto

Salvar um arquivo no editor e compilá-lo são operações diferentes. A compilação pode atualizar o repositório de objetos usado pelo ambiente. Quando esse RPO é compartilhado, o efeito alcança outras sessões que o utilizam.

Antes de compilar, registre servidor, porta, ambiente e a relação desse ambiente com o RPO. O nome “teste” no cadastro não basta para provar isolamento. Dois ambientes com nomes diferentes podem compartilhar componentes da infraestrutura.

A possibilidade de recompilar uma versão anterior também depende de tê-la guardado e de conhecer suas dependências. Um rollback planejado começa com versionamento e identificação do pacote, não com a esperança de encontrar uma cópia antiga depois.

Um mesmo atalho pode estar associado a comandos de extensões diferentes. Nas notas que originaram este artigo, duas extensões AdvPL do VSCode utilizavam combinações semelhantes para ações distintas. Isso torna perigoso interpretar o gesto como prova da operação.

Durante o diagnóstico, execute o comando pelo nome na paleta e confira o canal de saída que o registrou. Depois revise os atalhos efetivos da instalação. Não conclua que a ordem de ativação das extensões sempre produzirá o mesmo resultado.

Essa conferência é particularmente útil quando alguém diz “compilei igual ontem”, mas o log mostra geração de PPO ou outro comando. O primeiro problema a resolver é saber o que realmente foi executado.

3. Confundir PPO com compilação concluída

O pré-processamento expande includes e diretivas e produz uma representação intermediária. Ele ajuda a investigar o texto que chega às próximas etapas, mas não demonstra que o fonte foi compilado e incorporado ao RPO.

No TDS-LS examinado, appre e cli são modos distintos. Use o primeiro para a finalidade documentada e o segundo para a sequência de ações que você configurou. Encontrar um arquivo .ppo no disco não substitui a conferência do resultado de compilação.

O manual do script de execução consultado exige ANSI/CP1252 para o arquivo de comandos. As notas de trabalho também registram a necessidade de compatibilidade dos fontes com o compilador utilizado. Isso não autoriza ler todo arquivo como UTF-8 e sobrescrevê-lo cegamente.

Se o arquivo já estiver em CP1252, uma conversão feita com premissa errada pode corromper caracteres. Faça a conversão sobre uma cópia, identifique a origem e confira acentos nos literais. Uma sequência como Atenção costuma apontar para interpretação incorreta de bytes — e ela compila com sucesso, aparecendo só na tela do usuário.

O critério útil é preservar o texto esperado do começo ao fim. Quando a origem não for conhecida, compare com a versão no controle de fontes antes de transformar o arquivo novamente.

5. Compilar diretamente de uma pasta sincronizada

Uma pasta de nuvem pode estar sincronizando enquanto a ferramenta lê o fonte. O manual oficial do TDS-VSCode recomenda utilizar drives locais para evitar comportamentos adversos, inclusive leitura parcial durante compilação.

Prepare uma cópia local estável do conjunto que será compilado. Caminhos curtos ajudam no diagnóstico, mas trocar o nome da pasta não resolve um arquivo que ainda está sendo alterado por outra aplicação.

Guarde também a identificação da revisão utilizada. Sem ela, um log que diz “arquivo X compilado” não informa qual conteúdo daquele arquivo entrou no ambiente.

Ao automatizar um lote, o seletor de entrada vira parte da mudança. Uma pasta pode conter exemplos, arquivos antigos e fontes que não pertencem à entrega. O fato de estarem próximos no disco não significa que devem ser compilados juntos.

O formato oficial oferece program e programList, e orienta não usar ambos na mesma seção. Prefira uma lista explícita quando precisar revisar o conjunto. Leia a lista final antes da execução; não aprove apenas o script que a gera.

Uma alteração pequena merece uma entrada pequena e verificável. Isso reduz a chance de regredir outro componente por acidente.

7. Reaproveitar uma credencial no formato errado

Senha cifrada por uma extensão, token de autorização e senha de autenticação não são intercambiáveis. Cada mecanismo tem uma finalidade e um formato esperados. Copiar um valor entre configurações pode produzir uma falha que parece ser do servidor.

Use a forma de autenticação documentada para o executável e a versão selecionados. Se o processo exigir um arquivo temporário com segredo, restrinja o acesso e o tempo de vida desse arquivo. Não registre seu conteúdo no log nem o coloque no repositório.

Caracteres especiais devem ser tratados conforme o formato utilizado. A solução não é recomendar senhas mais fracas para contornar um problema de escape ou de parser.

8. Procurar apenas a palavra “success”

Um log pode registrar autenticação bem-sucedida e falha posterior de compilação — a palavra aparece em User authenticated successfully muito antes de qualquer fonte ser processado. Capture o código de saída imediatamente após o processo e confronte-o com o resultado final das ações previstas.

Mesmo um retorno zero precisa ser interpretado dentro da versão e do modo utilizados. Verifique arquivos processados, conclusão do build e ausência de mensagens conflitantes. Depois execute o teste funcional da alteração.