CMake: Как определить, откуда приходит транзитивная зависимость?

Я переписываю устаревшую настройку CMake, чтобы использовать современные функции, такие как автоматическое распространение зависимостей. (т.е. используя такие вещи, как target_include_directories(<target> PUBLIC <dir>)вместо include_directories(<dir>).) В настоящее время мы вручную обрабатываем всю информацию о зависимостях проекта, устанавливая набор глобальных свойств каталога.

В моем тестировании я обнаружил несколько примеров, когда цель в новой сборке будет ссылаться на библиотеку, а старая сборка - нет. Я не ссылаюсь на него явно, поэтому я знаю, что это происходит из зависимостей цели, но для того, чтобы выяснить, какие из них мне нужно рекурсивно просмотреть все проекты CMakeLists.txt, следуя иерархии зависимостей, пока не найду тот, который тянет в рассматриваемой библиотеке. У нас есть десятки библиотек, так что это не тривиальный процесс.

Предоставляет ли CMake какой-либо способ увидеть для каждой цели, какие из ее зависимостей были добавлены явно, а какие были распространены через транзитивные зависимости?

Похоже , что --graphvizвыход делает показать это различие, так ясно CMake знает контекст внутри. Тем не менее, я хотел бы написать treeподобный скрипт для отображения информации о зависимостях в командной строке, и анализ файлов Graphviz звучит как кошмар и взлом.

Насколько я могу судить, cmake-file-apiэто не включает эту информацию. Я думал, что codemodel/target/dependenciesполе может работать, но в нем перечислены как локальные, так и транзитивные зависимости, смешанные вместе. И backtraceполе каждой зависимости связывается только с вызовом add_executable/ add_libraryдля текущей цели.

cmake

— 0x5453
источник

Как --graphizвариант не ответить на ваш вопрос? Почему при разборе файлов с точками кажется кошмаром? Точечные файлы - это самый простой, распространенный и гибкий способ восприятия человеком связанных точек. С помощью gvprутилиты вы можете делать с ними все что угодно в стиле awk-ish и импортировать их на других языках. Почему точечный файл, который буквально представляет древовидную структуру зависимостей между целями, а не «способ увидеть» то, что вы просите?

— KamilCuk

@ KamilCuk Справедливо достаточно. Я думаю, что надеялся на более стандартизированный формат, такой как JSON, который я мог бы читать без установки дополнительных пакетов и без написания собственного анализатора. Я предполагал, что граф зависимостей будет доступен в нескольких форматах (мне все еще нужно поэкспериментировать с API сервера CMake , например). Но если точечные файлы - это самый простой (или единственный) способ получить эту информацию, это нормально.

— 0x5453

Я бы не стал ставить слишком много ставок на Графвиз, показывающий это по-другому. Код, который рассказывает об этом отдельно , связан здесь , он не очень сложен.

— Керт

Вы можете анализировать dotсгенерированный файл graphvizи извлекать детали, которые вы хотите. Ниже приведен пример скрипта Python для этого.

import pydot
import sys

graph = pydot.graph_from_dot_file(sys.argv[1])
result = {}

for g in graph:
    # print(g)
    for node in g.get_node_list():
        if node.get("label") != None:
            result[node.get("label")] = []

    for edge in g.get_edges():
        result[g.get_node(edge.get_source())[0].get("label")].append(g.get_node(edge.get_destination())[0].get("label"))

for r in result:
    print(r+":"+",".join(result[r]))

Вы также можете добавить этот скрипт для запуска из cmake как пользовательскую цель, чтобы вы могли вызывать его из вашей системы сборки. Вы можете найти образец проекта cmake здесь

— Мантан Тилва
источник

Спасибо за пример, мне нужно разобраться pydot.

— 0x5453