Não é para isso que são os makefiles. O Makefile apenas lida com a construção do software e a instalação no sistema de maneira genérica (sem um gerenciador de pacotes). Ele não se importa (e não deve se importar) se você tiver os requisitos para realmente executar o aplicativo. Isso é por design. Considere vários pontos:
1) Se a sua distribuição usa um gerenciador de pacotes (quase todos eles de alguma forma), você não deve chamar make install diretamente, porque isso ignora o gerenciador de pacotes e polui seu sistema. Nesse caso, make install é chamado em um ambiente "sandbox" quando você constrói o pacote, a instalação é empacotada e o pacote é instalado e manipulado pelo gerenciador de pacotes de sua preferência.
2) Não deve haver necessidade de instalar tudo na ordem "correta". Na verdade, isso certamente levará a dependências circulares e será impossível instalá-lo. Até mesmo os gerentes de pacotes geralmente são muito rigorosos sobre isso, o que leva a problemas. Além disso, quando você está construindo um pacote (um compilação chama make install ), na verdade você não pretende executar o programa e provavelmente não tem os requisitos instalados de qualquer maneira. Afinal, você está apenas construindo um pacote que será instalado em outro computador.
3) Não há uma maneira portátil de fazer isso. Como é que o seu make install , que é por definição independente da plataforma, sabe onde procurar os requisitos (URLs hardwired ou algo do tipo? Que irromper em um segundo!). Ele não pode passar pelo gerenciador de pacotes porque ele deve ser executado em todas as possibilidades, incluindo as futuras que você não previu - também as versões mudam.
4) Não há uma única decisão sobre o que instalar. Bibliotecas compartilhadas podem ser fornecidas por diferentes pacotes. Há mais de um libc , mesmo. E mais de um pacote que fornece funcionalidade OpenGL (placas gráficas diferentes), pacotes diferentes para álgebra matricial, bibliotecas diferentes para reprodução de mídia (vlc vs. gstreamer), e eu poderia continuar por muito tempo. A escolha é sua, como você projeta seus sistemas e quais componentes você usa, é a beleza deste design modular (ao invés do velho clássico windows de colocar tudo em um CD / DVD, e assim ter cada biblioteca instalada mil vezes por pacotes diferentes, e gigabytes de instalação para cada aplicativo que não deve exceder 10 MB com um design são).
5) Não é o trabalho de make install , é um nível diferente de manutenção. configure && make && make install manipula a verificação do que você instalou (para dependências de tempo de construção), compila o código e mostra onde os arquivos devem ser colocados. Requisitos sobre quais versões de outros softwares você precisa se encaixam no domínio de empacotamento e distribuição, que é um processo separado - o gerenciador de pacotes ou o administrador do sistema se ele instala as coisas da maneira tradicional. Você nunca deve misturar esses dois conceitos - isso levaria ao caos. Se as coisas forem separadas em camadas bem definidas, os desenvolvedores podem mudar coisas independentes dos empacotadores e gerenciadores de distribuição: se a distro decide reempacotar coisas com nomes diferentes e usar alternativas diferentes, coloque coisas em diretórios diferentes, elas não devem esperar que o aplicativo desenvolvedor, que cuida do makefile, para saber ou se importar com isso.
Resumindo - não importa se as dependências são dependências de tempo de construção (sem as quais o make não pode ser executado - o que geralmente é detectado pelo script configure ) ou as dependências de tempo de execução, isso não deve ser feito em o nível makefile. Por favor, não faça as coisas do jeito errado e considere os padrões. Se você está lidando com algo que ainda não tem pacote (verifique os pacotes fornecidos pelo usuário, pode estar lá), você deve investigar o que é necessário e realmente construir o pacote - é melhor para os outros também, pacote que você fez.