Как мне заставить make определить правильные зависимости для линковки в правильные нижележащие объектные файлы?

Я собираюсь использовать небольшой пример для справки. Рассмотрим проект с:

inner_definitions.o : inner_definitions.cpp inner_definitions.h
    gcc $^ -o $@

inner_class_1.o : inner_class_1.cpp inner_class_1.h inner_definitions.h
    gcc $^ -o $@    

inner_class_2.o : inner_class_2.cpp inner_class_2.h inner_definitions.h
    gcc $^ -o $@

outer_class.o : outer_class.cpp outer_class.h inner_class_1.h inner_class_2.h
    gcc $^ -o $@

executable.o : executable.cpp executable.h outer_class.h
    gcc $^ -o $@

executable : __?1__
    __?2__

Но заполнить пробелы __? 1 __ для зависимостей компоновщика и __? 2 __ для команды компоновщика непросто.

В этом небольшой пример, можно утверждать, что легко увидеть, что __? 1__ = inner_definitions.o inner_class_1.o inner_class_2.o external_class.o исполняемого файла.o . Однако это явно не масштабируемое решение, так как оно заставляет каждого разработчика понимать все зависимости кода, с которым они работают, чтобы они могли выяснить зависимости вручную , а не с помощью make утилита.

Другим решением было бы иметь разные переменные для каждого объектного файла, в котором перечислены все его нисходящие зависимости: т.е. __? 1__ = executable.o $ (executable_dependencies) . Это нежелательное решение, потому что оно заставляет make-файл компилироваться определенным образом, поэтому переменные используются только тогда, когда они полностью определены. Кроме того, для действительно больших приложений эти переменные могут превышать максимальную длину переменной.

Еще одно решение - использовать архивные файлы .a для связывания. В этом случае мы могли бы построить inner_class_1.a , который включал в себя как inner_defintions.o , так и inner_class_1.o , чтобы его можно было связать с любым объектным файлом, который требуется inner_class_1.o , не заставляя разработчика восстанавливать зависимости. Этот подход кажется многообещающим, но предполагает наличие множества повторяющихся файлов. Также не похоже, что компоновщик gcc может обрабатывать вложенные архивные файлы.

Есть ли другой подход? Какой подход лучше? Может ли компоновщик gcc обрабатывать вложенные архивные файлы?