Зависит от версии make.
3.79 и 3.81 заметно отличаются по поведению.
3.79 и 3.81 заметно отличаются по поведению.
В этом месте ничего отличаться не может.
что-то типа такого:
%.o: %.c Makefile
$(CC) -Wp,-MMD,.$<.d -o $@ -c $(CFLAGS) $<
-include .*.d
что-то типа такого:
%.o: %.c Makefile
$(CC) -Wp,-MMD,.$<.d -o $@ -c $(CFLAGS) $<
-include .*.d
вы вот видели выше и ниже примеры ?
И эти люди ругают MSVSи запрещают ковыряться мне в носу
ужаснах !
И эти люди ругают MSVS
ужаснах !
Ну, чисто для экзотики, есть еще qmake и непаханное поле вокруг ant.
Вся Java собирается на makefile, JavaFX на ant, JavaFX Webkit - qmake.
Собственно это три альтернативы для действительно кроссплатформенной сборки.
Рано или поздно, но все виденные мной проекты с устоявшейся структурой
докатывались до ручных makefile. Хотя личинки этих файлов за заре быстрого
роста генерировали разными тулами (чаще - самописными).
Вся Java собирается на makefile, JavaFX на ant, JavaFX Webkit - qmake.
Собственно это три альтернативы для действительно кроссплатформенной сборки.
Рано или поздно, но все виденные мной проекты с устоявшейся структурой
докатывались до ручных makefile. Хотя личинки этих файлов за заре быстрого
роста генерировали разными тулами (чаще - самописными).
Скажем, если в проекте есть что-то кроме компиляции C/C++, то без ручного makefile никак.
> -include .*.d
если эти .d появились после запуска make, то старый мэйк вроде как не подхватывал такие изменения.
если эти .d появились после запуска make, то старый мэйк вроде как не подхватывал такие изменения.
Автоматом должны такие вещи создаваться, и только автоматом. Это же не прикладная вещь, а служебная! Впрочем, тут по треду все уже описали, как зависимости вынимаются автоматом.
Эти объектники собирать в любом случае, поскольку их ещё нет -- зависимости не нужны.
Нет, главное, что есть механизм генерации этого дела автоматом. Это ок.
Это такой же исходный код как и любой другой.
И что, имеет какой-то смысл поменять этот исходный код и написать его как-то иначе? :)
MSVS в той части, которая MSVC, нередко ломается на вычислении зависимостей и начинает что-то рандомно перелинковывать.
Да ладно. cmake, add_custom_command и прочее.
В не совсем тривиальном случае -- имеет.
Двойной проход. По моему идея ок.
Вот. То есть основное время оно должно создаваться само. Типа как в QtCreator :)
1) пропишыте только в зависимости тех, у кого он явно включен.
2) Ну да, для особо ленивых есть gcc -M и практика цэли make depend.
2) Ну да, для особо ленивых есть gcc -M и практика цэли make depend.
autotools будет правильно только для ящериков. Поскольку вот где ужоснах, spaghetty code, test-driven genetic development и прочие чудеса.
У автокрэпа нет вещей, с котормы было бы хорошо.
Ну вот есть такая дерективка (это борланд мэйк)
.path.cpp= .
которая тупо включает все файлы с нужным расширением в указаной директории ;)
По идее вот аналог для линуха
vpath %.cpp $(SRC)
что выше в примере мейкфайла скинули
А так да, читать мануалы -- без этого никуда. Сам было потратил было некоторое время, на то чтобы понять как же этот мейк работает.
.path.cpp= .
которая тупо включает все файлы с нужным расширением в указаной директории ;)
По идее вот аналог для линуха
vpath %.cpp $(SRC)
что выше в примере мейкфайла скинули
А так да, читать мануалы -- без этого никуда. Сам было потратил было некоторое время, на то чтобы понять как же этот мейк работает.
автотулзы нас всех переживут и еще станцуют джигу на похоронах qmake-ов и ant-ов
.d - это не объектники, а описание зависимостей.
И? Они нужны что бы выяснить нужно ли пересобирать данный объектник. Если объектника нет -- ответ очевиден.
Page 2 of 4