Исходя из описанных вами требований, я думаю, что лучше всего подойдет CDT Build Output Parser . Я написал объяснение того, как использовать его в этом предыдущем ответе .
По сути, анализатор выходных данных сборки вызывает ваш скрипт сборки и анализирует его выходные данные, чтобы вывести правильные настройки (-I и-D flags) для каждого исходного файла.
Примечание по анализу файла в нескольких конфигурациях: CDT поддерживает это для заголовочных файлов , но не для исходных файлов без заголовков (таких как .c файлов). Итак, если у вас есть заголовочный файл header.h, который имеет несколько #ifdef с и включен в два разных исходных файла file1.c и file2.c с разными макросами, определенными в точке включения - тогда вы можете открыть header.h из #include в file1.c и получите правильное представление "header.h в комплекте с file1.c", с правильными частями, выделенными серым цветом, и все. Однако, если file1.c сам скомпилирован в двух разных режимах, я подозреваю, что анализатор сборки сборки просто выберет один из них, и вы застряли, просматривая его в этом режиме.