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 берет свое :)

MasterZivWhite OwlЯ абсолютно убежден что CMake (да и autotools) это ненужный костыль с гигантскими ограничениями. Ты абсолютно неправ.
Как бы чтобы это доказать, достаточно поискать в сети проекты аналогичного назначения и прочитать мотивацию к их созданию.
Очень хорошо это написано в Ant е.
Почитай.Чтобы доказать что я прав: достаточно вспомнить что и CMake и autotools выдают на выходе makefile который будет исполняться тем-же самым make. Спрашивается, чем кроме костыля эти инструменты могут быть?
А мотивация создания у костыля только одна - человек не может ходить на своих родных ногах, вот и изобретает дополнительные.

Мотивация для создания Ant чуть более серьезная: у Sun был своя версия Solaris-only сборщика и когда Sun начала выкладывать свои проекты в открытый доступ этот собственный сборщик был переписан в кросс-платформенный.
Почему у Sun был свой собственный сборщик, тоже более-менее понятно - коммерческая контора боялась использовать открытый инструмент.

Как это все делает меня неправым в моем предыдущем утверждении?

Анатолий ШироковWhite Owlпропущено...
Чтобы доказать что я прав: достаточно вспомнить что и CMake и autotools выдают на выходе makefile который будет исполняться тем-же самым make. Спрашивается, чем кроме костыля эти инструменты могут быть?
А мотивация создания у костыля только одна - человек не может ходить на своих родных ногах, вот и изобретает дополнительные.


Рассуждение на уровне - yacc, lex костыль для тех кто матрицу переходов LALR грамматики составлять сам не хочет.Принцип верен, но расстояние между CFG и исходником с LALR намного больше чем разница между входным файлом CMakeList.txt и makefile.
Не смотря на то, что я делал ручные переводы из CFG в LALR (два раза в код на О'Caml, один раз в С) я не смогу сходу взять любую грамматику и закодировать автомат для нее. Но взяв любой CMakeList.txt я могу почти сходу написать соответствующий makefile. Подглядеть в доку на CMake понадобится пару раз, но и только.
Так что нужность Яка с кузенами я признаю, нужность CMake - не признаю.

Анатолий ШироковВсегда следует отдавать предпочтение абстрактному описанию с последующей кодогенерацией ручному кодированию. Резон очень прост - всегда соскочить можно просто меняя кодогенератор.Здесь ключевое слово "абстрактному описанию". У CMake описание совсем не абстрактное, а очень даже конкретное.

Анатолий ШироковКак ты можешь соскочить с make мне не очень понятно.А зачем мне с него соскакивать, простите?

MasterZivТы абсолютно неправ. Прогресс не остановить. Ура.Да, да. Все знают что я ретроград и пещерный человек.

Анатолий ШироковWhite Owlпропущено...
Здесь ключевое слово "абстрактному описанию". У CMake описание совсем не абстрактное, а очень даже конкретное.

Я не случайно привел описание одного из наших проектов, чтобы показать, что синтаксис описания вполне себе пригоден для звания "абстрактного описания". Нет, не пригоден. Хорошо, перефразирую: Уровень абстракции у CMake абсолютно такой же как и у make.

Абстрактное описание сборки (как я его понимаю) это то что у меня есть на уровне корня проекта: Собрать специальные инструменты используемые для сбора программы, собрать промежуточные библиотеки, собрать программу, собрать плагины. Причем именно в этом порядке (хотя плагины можно собирать и параллельно с программой).

Вот пример:



То что в своем CMakeList.txt ты не показываешь как конкретно надо компилировать .cpp ничего не значит. Я в своем makefile тоже могу этого не показывать.
Вот тебе makefile от одного из плагинов:


Как видишь, количество кода описывающего сценарий точно такое-же как и у CMake. Уровень абстракции описания тоже совпадает.


Анатолий ШироковWhite Owlпропущено...
А зачем мне с него соскакивать, простите?Вопрос твой ожидаемый. Но мало ли, захочешь подебажить свой проект под студией. Я себе это могу повзолить просто сгенерировав solution под конкретную версию студии? А ты как этого достигаешь? Конечно, если речь идет о небольшом проекте, то можно и накидать на коленке студийный проект, но когда у тебя 600 модулей со сложными взаимосвязями, то здесь без чего-либо отвязанного от конкретной среды сборки просто необходимо.Смеешься?!
600 модулей написанных для одного компилятора запихнуть в другой компилятор и просто так подебажить? Ну-ну... То-то тут постоянно возникают вопросы: "почему в vc это работает а в g++ не работает?", и наоборот. А ты сводишь всю сложность межкомпиляторного перехода к переводу сценария сборки? Шутник.

И нет, я не захочу дебажить проект под студией. Во первых, для дебага есть логи, во вторых dbg. Зачем мне студия?