Estou reescrevendo uma instalação herdada do CMake para usar recursos modernos, como a propagação automática de dependências. (ou seja, usando coisas como em target_include_directories(<target> PUBLIC <dir>)
vez de include_directories(<dir>)
.) Atualmente, lidamos manualmente com todas as informações de dependência do projeto, definindo várias propriedades de diretório global.
Nos meus testes, encontrei alguns exemplos em que um destino na nova compilação será vinculado a uma biblioteca que a compilação antiga não faria. Não estou vinculando-o explicitamente, portanto, sei que isso é proveniente das dependências do destino, mas, para descobrir qual delas, preciso procurar recursivamente todos os projetos CMakeLists.txt
, acompanhando a hierarquia de dependências até encontrar um que puxa a biblioteca em questão. Como temos dezenas de bibliotecas, esse processo não é trivial.
O CMake fornece alguma maneira de ver, para cada destino, quais de suas dependências foram adicionadas explicitamente e quais foram propagadas por dependências transitivas?
Parece que a --graphviz
saída não mostrar esta distinção, tão claramente CMake conhece o contexto internamente. No entanto, eu gostaria de escrever um tree
script semelhante para mostrar informações de dependência na linha de comando, e analisar os arquivos Graphviz parece um pesadelo e um hack.
Tanto quanto eu posso dizer, cmake-file-api
é que não incluem esta informação. Eu pensei que o codemodel/target/dependencies
campo poderia funcionar, mas lista as dependências locais e transitivas misturadas. E o backtrace
campo de cada dependência apenas se vincula à chamada add_executable
/ add_library
para o destino atual.
--graphiz
opção não responde à sua pergunta? Por que analisar arquivos de ponto parece um pesadelo? Os arquivos de ponto são a maneira mais simples, comum e flexível de representar pontos conectados, legíveis por humanos. Com ogvpr
utilitário, você pode fazer qualquer coisa com eles no estilo awk-ish e importá-los para outros idiomas. Por que um arquivo de ponto, que literalmente representa uma estrutura em árvore de dependências entre destinos, não é uma "maneira de ver" o que você pede?