Про -MM уже сказали. Подробно и аккуратно, если это линукс и, соответственно, GNU make, разобрано в его мануале. В целом - решение далеко от идеала, но лучше средствами make не делается, вылезает проблема курицы и яйца. У bsd make (pmake в линуксах) средства иные. Сделать makefile так, чтобы жрали оба - задача сложная, и автоподхват зависимостей будет делаться только в два прохода (make depend && make).
Да, в случае генерируемых включаемых файлов gcc -MM тоже порой обламывается.
Кстати, вообще рекомендую посмотреть на "старую добрую" идею двухпроходного подхода. Она тоже по-своему корява, но зато мейкфайл будет читаем.
Лично я руками пишу. У меня уже три Makefile в проекте, общей сложностью (wc -l) 6641 строки :) правда, из них не меньше трети пробелов и комментариев. Много ли у вас там зависимостей? Тем более, один раз вы их пропишете, и все, потом только добавляй.
Читал, кстати, как-то раз совет насчет сделать один .h файл типа такого:
#ifdef USE_THIS
... код для this ...
#endif
#ifdef USE_THAT
... код для that ...
#endifM
Потом каждый .c файл его включает, но объявляет, что именно он использует:
#define USE_THIS
#include "myheader.h"
Для меня это неактуально, но вообще такой файл выглядит довольно удобной идеей.
Собственно, что это я: конкретно в вашем use case можно, скажем, сгруппировать цели по зависимостям:
foo.o bar.o: baz.h
foo.o: foo.c foo.h
рецепт
Но это может быть не очень удобно, потому что зависимости идут в неочевидном порядке (хотя, по-моему, они будут в том же порядке, что и в файле), и несколько трудно писать стандартные рецепты с использованием символов вроде $<.
Ну, чисто для экзотики, есть еще qmake и непаханное поле вокруг ant.
Вся Java собирается на makefile, JavaFX на ant, JavaFX Webkit - qmake. Собственно это три альтернативы для действительно кроссплатформенной сборки. Рано или поздно, но все виденные мной проекты с устоявшейся структурой докатывались до ручных makefile. Хотя личинки этих файлов за заре быстрого роста генерировали разными тулами (чаще - самописными).
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Вопрос зависимостей для C/С++ там как правило разбирают.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
no subject
А по простецки dependencies можно gcc попросить сделать: gcc -MM file.c
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
Да, в случае генерируемых включаемых файлов gcc -MM тоже порой обламывается.
Кстати, вообще рекомендую посмотреть на "старую добрую" идею двухпроходного подхода. Она тоже по-своему корява, но зато мейкфайл будет читаем.
no subject
Компиляция под х86 сломана, но леххко чинится по аналогии (делаем эльф)
no subject
Читал, кстати, как-то раз совет насчет сделать один .h файл типа такого:
Потом каждый .c файл его включает, но объявляет, что именно он использует:
Для меня это неактуально, но вообще такой файл выглядит довольно удобной идеей.
no subject
Но это может быть не очень удобно, потому что зависимости идут в неочевидном порядке (хотя, по-моему, они будут в том же порядке, что и в файле), и несколько трудно писать стандартные рецепты с использованием символов вроде
$<
.no subject
no subject
Вся Java собирается на makefile, JavaFX на ant, JavaFX Webkit - qmake.
Собственно это три альтернативы для действительно кроссплатформенной сборки.
Рано или поздно, но все виденные мной проекты с устоявшейся структурой
докатывались до ручных makefile. Хотя личинки этих файлов за заре быстрого
роста генерировали разными тулами (чаще - самописными).
(no subject)
(no subject)
no subject
.path.cpp= .
которая тупо включает все файлы с нужным расширением в указаной директории ;)
По идее вот аналог для линуха
vpath %.cpp $(SRC)
что выше в примере мейкфайла скинули
А так да, читать мануалы -- без этого никуда. Сам было потратил было некоторое время, на то чтобы понять как же этот мейк работает.
(no subject)
(no subject)
(no subject)
no subject
(no subject)
no subject
no subject
Ни одной O_o