Есть ли хорошие советы или инструменты для удаления сторонних библиотек C и C ++ из кодовой базы? (OS X или Linux)

Я нахожусь в процессе сокращения и карантина использования некоторых библиотек. Многие существующие программы, которые я написал, напрямую используют эти библиотеки. Я бы хотел, чтобы компилятор (в данном случае GCC и / или Clang) или какой-либо инструмент помогли мне определить эти варианты использования в моей кодовой базе.Короче говоря, я хотел бы воспрепятствовать использованию этих библиотек во всей кодовой базе, за исключением того, что они будут использоваться одной библиотекой, и эта одна библиотека будет видна другим модулям в моей кодовой базе.

Вопрос:

1) Знаете ли вы инструменты, которые могут помочь мне в этом?

2) или вы можете порекомендовать некоторые стратегии, чтобы облегчить этот процесс?

Условия и детали:

• Удаление их включений невозможно.
• Поиск неэффективен из-за размера моей кодовой базы и количества символов, которые я хочу поместить в карантин.
• Использование инструментов рефакторинга будет слишком утомительным, учитывая сложность кодовой базы и количество символов, которые нужно удалить.
• Исключение поддержки символов по отдельности невозможно из-за большого количества объявлений в сторонних библиотеках.
• Интерфейсы сторонних библиотек написаны в основном на C.
• Переводы будут на C ++ и Objective-C ++.
• Уловки препроцессора не изящны для способа настройки моих сборок и могут изменить слишком много файлов.
• Не нужно отказываться от каждого последнего использования. В идеале они были бы таковыми, но в большинстве случаев удовлетворительны. Это требование не просто потому, что нужно слишком много обновлять.
• Удаление их со стадии связывания в этом случае не лучший вариант (подробно описано в Обновлении №3).
• В идеале этот инструмент или стратегия были бы доступны в OS X, но я также могу создать значительную часть программ, ориентированных на Linux.

Некоторые стратегии, которые пришли в голову:

Лучшее, что я придумал для этого случая, - это повторно объявить типы, используемые библиотекой, и украсить их устаревшими атрибутами:

typedef IHREType IHREType __attribute__((__deprecated__));

Но это победа ' t охватывают все случаи, и отношение сигнал / шум будет довольно высоким после нескольких итераций.

Альтернативой было бы повторно объявить эти типы в корневых пространствах имен, которые я использую:

namespace MON {
typedef t_poisoned IHREType;
}

, но это станет немного запутанным.

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

Обновление №1

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

Обновление №2

Добавлен Linux из-за малого количества ответов.

Обновление №3

> > Justin: Removing them from the link stage is not a good option in this case.
> thiton: Why not? 

Чтобы уточнить этот момент: мне нравится, как сейчас расположены библиотеки и проекты. Есть сочетание статических и динамических библиотек. Изменение этой структуры и синхронизация зависимостей отнимают много времени (хотя отдельные случаи могут быть хорошим использованием времени для некоторых библиотек ...). Компоновщик также разрешает большое количество символов, которые я хочу удалить из-за зависимостей (например, в системных библиотеках).

План, который у меня есть для этого

В базе кода есть сотни проектов Xcode (добавьте к этим проектам для других разработчиков / IDE).

Я сосредоточусь на этих обновлениях несколько дней здесь и несколько дней там; 100% охват не является реалистичной целью для данного периода времени и в настоящее время не является требованием. Из-за размера задачи и текущего состояния кодовой базы я хотел бы сосредоточиться на удалении вхождений по номерам в настоящее время. Удаление по номеру также предпочтительнее, потому что это в конечном итоге приведет к меньшему времени на сборку (требуется время, чтобы построить все это). Как только это уменьшится, я перейду к полному устранению - по крайней мере, это мой текущий план. В этом случае,У меня есть время выполнить обновления, но это пока не срочно. Если ваша рекомендация отличается от этой модели, у меня есть гибкость.