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

Я б не ставлю занадто багато ставок на Graphviz, показуючи це по-різному. Код, який розповідає про це , пов'язаний тут , він не дуже складний.

— kert

Ви можете проаналізувати 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