LowCoderВопрос гуру make – как организовать правильно (так что би через 20 лет было не стыдно) make файл для следующего:Возьми десяток многолетних open source проектов и посмотреть как это обычно делается.

LowCoderЕсть три проекта с++. Все они лежат в общей папочке. Один из проектов как бы главный и использует остальные два. Остальные два могут собираться в своих папочках в основном для исполнения UNIT тестов.Если хочешь делать на чистом make, то читай главы 4.6 Phony targets и 5.7 Recursive Use. Там даже примеры есть как организовать работу с под-проектами.

LowCoder Однако главная цель таки собрать основной проект для 32 и 64 платформ.Чем эти проекты отличаются друг от друга?
Вот у меня сейчас один и тот-же проект пишется на WinXP-32 и на Linux Debian 64. Один и тот же makefile, никаких поклонов в сторону ОС или битности нет вообще. Из makefile я вызываю просто gcc - а он уже сам знает на какой ОС он живет и какая целевая платформа.

Ну а если тебе действительно нужно какие-то специфические бубны для битности делать то можно например так:

А потом можешь запускать make platform=32. Но в 99% случаев у тебя будет в системе какая-нибудь переменная которая однозначно подскажет платформу и вручную ее почти никогда задавать никогда не нужно. Ну разве что если ты делаешь кросс-компиляцию и хост-платформа не совпадает с целевой.

LowCoderВопрос как лучше поступить - сделать основной Makefile в общей папочке и держать в каждой подпапочке свой Makefile и основной Makefile просто будет инклюдить все остальные и можно ожидать что они будут последовательно исполнятся. Только не инклудить а вызывать.
В случае инклуда у тебя будет последовательное исполнение одного единственного скрипта сборки. И его всегда надо будет вызывать из корневого каталога. А если делать независимые сценарии для каждого подпроекта плюс один сценарий с subdirs в корне проекта, то можно будет собирать любой кусок проекта независимо (или зависимо от других). Опять таки, читай главу 5.7, там есть примеры.

LowCoderили держать два Makefile каждый для своей платформы в отдельных подпапках или как? Или скрипты специальные строительные сделать...Если нужно (удобнее), то можно сделать. что-то в духе:




Но в таком разделении есть смысл только если платформо-зависимых флагов много и их удобнее держать в отдельных файлах.

MasterZivавторВопрос гуру make – как организовать правильно (так что би через 20 лет было не стыдно) make файл для следующего:
Чтобы совсем не стыдно было через 20 лет, надо правильно организовать сборку проекта на CMake.У CMake смысл только один - если ты будешь собирать проект в разных make'ах. Вот если ты хочешь одновременно писать на GNU C/C++, на MS Visual Studio, и на каком-нибудь Borland - то CMake может быть полезен.
Но на самом деле люди выбирающие CMake просто не умеют писать makefile. Я абсолютно убежден что CMake (да и autotools) это ненужный костыль с гигантскими ограничениями. Все что могут делать эти уродцы (CMake и autotools) можно сделать на gnu make с той-же легкостью и намного большим контролем над происходящим. При этом, make есть под все платформы и не привязан ни к одному транслятору.

Anatoly MoskovskyWhite Owl,

А как просто в make сделать, что если в хедере изменилась только дата файла, то не надо перекомпилировать все что от него зависит?Если ты мне объяснишь смысл этого желания я тебе объясню как это сделать.
По моему, если дата заголовка изменилась, НАДО перекомпилировать все что от него зависит.

Anatoly MoskovskyWhite Owl,

А как просто в make сделать, что если в хедере изменилась только дата файла, то не надо перекомпилировать все что от него зависит?Но вообще-то, это сделать элементарно. Просто убери зависимость от заголовка и все.

А если все совсем плохо, и тебе надо убрать заголовок из уже объявленного списка заголовков, то filter-out спасет:

Anatoly MoskovskyWhite OwlЕсли ты мне объяснишь смысл этого желания я тебе объясню как это сделать.
По моему, если дата заголовка изменилась, НАДО перекомпилировать все что от него зависит.
А по-моему дата исходника никак не должна влиять на компиляцию - в ней не содержатся никакие данные от которых зависит содержимое конечного бинарника.Дата исходника это главный источник ответа на вопрос: "изменился исходник или нет?"

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

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

Anatoly MoskovskyДа и вообще, мало ли что вы себе не представляете. Вселенная гораздо шире, чем ваш личный опыт :)Ну вот и обогати мой опыт пожалуйста.

Anatoly MoskovskyWhite OwlХорошо, показывай альтернативу make которая способна узнать что файл вернули в предыдущее состояние.
scons умеет и по дате и по содержимому зависимости строить.Не совсем корректная альтернатива. scons это не инструмент, а библиотека. Пользуясь которой можно написать программу сценария. Если хочешь корректно сравнивать scons и make, то бери makefile в котором каждое правило расписано через $(shell ...).
В принципе, у scons есть положительные моменты. И я бы его пожалуй попытался бы использовать если бы он не был написан на Питоне. Вот когда его перепишут на чем-либо более надежном тогда и будем брать его в реальную работу. А пока, при всех своих достоинствах и умениях scons это симпатичная идея напрочь убитая собственным фреймворком.

Anatoly MoskovskyWhite Owlscons это не инструмент, а библиотека.
Да-да, а когда вы в ком. строке набираете scons - это вы пишете код использующий эту библиотеку ?Нет, набирая scons в командной строке я запускаю скрипт который подгружает файл SConstruct как модуль и выполняет его. А вот когда я пишу содержимое файла SConstruct - то да, я пишу программу на Питоне 2.4 использующей эту библиотеку. Да... А если у меня стоит Питон 3.2, то scons мрёт почти сразу. А если 2.6 то работает, но потом тоже мрёт. Потому что Питон не совместим сам с собой. Поэтому не смотря на все плюшки scons'а - я очень не советую использовать его в серьезных проектах.

Из более-менее серьезных альтернатив gnu make я могу назвать только makepp. Вернее это альтернатива для scons. Тот же самый принцип, только Перл вместо Питона и при этом полная обратная совместимость со стандартным make.
Единственный минус makepp - его малая известность.
Я сам, если честно, только документацию на него читал, да ради прикола несколько примеров попробовал. А на практике, привычка к make берет свое :)