Como Trabalhar com Libraries sem Pacotes


Como seria trabalhar em um projeto que utiliza libraries que não possuem pacotes? Se cada desenvolvedor tiver cópias das libraries em paths diferentes, as configurações do projeto não devem utilizar paths pré-determinados.

Unsplash image Photo by Aditya Romansa on Unsplash

Pacotes facilitam muito o desenvolvimento, pois eles registram na IDE onde estão o código-fonte de suas libraries. Assim, cada desenvolvedor pode ter suas próprias cópias de libraries salvos em quaisquer pastas em seus computadores.

Um projeto que utiliza pacotes apenas irá fazer referência à eles e deixará a IDE o trabalho de localizá-los para informar ao compilador os códigos-fontes referentes aos pacotes.

Mas, e se uma library não possuir pacotes?

Nesse caso basta adicionarmos o path da library no search path do projeto. Ao compilarmos, os fontes serão localizados pela IDE.

Funciona. Porém, se o projeto tiver muitos desenvolvedores, como garantir que todos irão utilizar o mesmo path? Há uma grande possibilidade de haver divergências de paths em projetos colaborativos com mais de um desenvolvedor.

Desenvolvedores podem utilizar diferentes paths para projetos, componentes e libraries. Cada um organiza seus projetos da forma que achar melhor em seus próprios computadores.

Um projeto sem pacotes não tem a ajuda da IDE para localizar os fontes. O desenvolvedor deve informar onde eles estão. Como cada desenvolvedor “gosta” de ter sua própria hierarquia de pastas, como configurar o search path do projeto?

Macros.

No Lazarus há macros que podem ser interpretadas em run-time pela IDE.

A macro que precisamos para resolver o problema de paths é a $Env(name).

Agora, imagine um library chamada DBFast, sem pacotes.

O desenvolvedor José tem a cópia da library em c:\dev\libs\dbfast enquanto o Márcio tem a mesma library em d:\pascal\components\dbfast.

Dois paths bem diferentes para um mesmo projeto.

Felizmente, utilizando macros a configuração é simplificada.

José e Márcio devem criar uma variável de ambiente em seus computadores apontando para esses paths. A variável de ambiente deve ter o mesmo nome, por exemplo, DBFastSource.

Finalmente, basta adicionarmos a macro $Env(DBFastSource) no search path do projeto para que tudo funcione com paths diferentes para cada desenvolvedor.

Até logo.

Posts Relacionados

  • Memória Segura Utilizando Instâncias de Interfaces

  • Classes Mutáveis vs Objetos Imutáveis

  • Implementando Interfaces Utilizando Diferente Assinaturas de Métodos

  • Usando Paths ao invés de Diretivas de Compilação

  • Trabalhando com Exceções em Requisições HTTP

  • Tipo object Continua Vivo

  • Array de Objetos

  • Variáveis Locais Deveriam ter Nomes Curtos

  • Como Dividir e Organizar o Código em Formulários com Muitos Widgets

  • Pascal Deveria ser Modernizado?