Qual é a melhor abordagem para verificar dependências de bibliotecas de terceiros durante a compilação das fontes?

Question

Eu não entendo uma coisa relacionada com a compilação do projeto a partir da fonte.

Como devo reagir quando a biblioteca de terceiros está ausente? Qual é a melhor abordagem para resolver este tipo de problema?

Por exemplo, eu clonei algum código do github. A documentação diz que a única coisa que devo fazer é executar o makefile. Mas durante a compilação eu consegui:

libmy/include/somefile.h:16:10: fatal error: 'GL/gl.h' file not found
#include <GL/gl.h>

O que devo fazer? Eu posso começar a pesquisar o que é GL / gl.he eu vou encontrar informações sobre o pacote que devo instalar. Mas não acredito que tenha que procurar cada cabeçalho perdido. Não pode ser uma boa solução.

Eu posso usar algo como pesquisa de arquivo apt e talvez eu encontre a biblioteca que eu devo instalar. Mas ainda assim, tenho que verificar todos os arquivos ausentes dessa maneira.

Suponho que o problema esteja no projeto. Mas eu não sei como isso deve ser consertado. O makefile deve verificar se tudo está instalado?

Eu li sobre o pkg-config que parece algo que pode ajudar no meu problema. Devo usar o pkg-config para verificar a biblioteca ausente?

E se pkg-config estiver faltando ou o usuário não quiser instalá-lo?

Existe alguma solução melhor para resolver este tipo de problema?

    

Answer 1

Muitos pacotes contêm o script especial configure , cuja intenção é verificar quais dependências estão instaladas na máquina host. Outros passam por outros mecanismos, que geralmente são mencionados nos arquivos README ou INSTALL dentro de um pacote fonte. Poucos podem ir e ser compilados como programas independentes e eles não tentam detectar dependências ou eles não têm nenhum.

Se você pegar o código do GitHub, então você deve estar pronto para código incompleto que acaba não compilando assim. Então, se você claramente não pode nomear o arquivo que é a partir de qual dependência (e código que você está baixado não tem documentação), você só pode google-lo. Além disso, muitos nomes de arquivos de cabeçalho são lembrados à medida que sua experiência Unix cresce: -)

Pacotes razoáveis possuem scripts (ou outros mecanismos) para verificar dependências e / ou documentação que diz quais dependências você precisará, pacotes incompletos ou ruins não têm nada disso.