или "императивное vs деклатативное описание проектов".
Исторически make-файлы появились раньше. Они связаны с интерфейсом командной строки, который был тогда единственным. По сути make-файл это скрипт на каком-то языке, который позвляет вызвать компилятор, линкер и множество других программ с любыми опциями. Организовать какую-то логику (иногда весьма нетривиальную). Все компиляторы так или иначе до сих пор поддерживают интерфейс командной строки и опции, передаваемые через него.
С другой стороны, файл проекта, в котором проект описан более-менее декларативно. Можно рассмотреть файлы Visual Studio (vcproj, vcxproj). Наличие удобных визуальных средств редактирования этих файлов (диалоги свойств проекта в студии). Строгая, более-менее декларативная структура (хотя возможности задать pre/post build steps тоже есть). Нет необходимости изучать еще один язык программирования. Значительно снижена вероятность ошибки при редактировании.
Лично мне больше нравится декларативный подход в виде project файлов (при условии грамотного проектирования структуры этих файлов и возможно даже включения базовых требований к структуре в спецификацию языка программирования). А make-файлы я как не понимал, так и не понимаю (поэтому возможно, мое мнение субъективно). Интересно ваше мнение.
Здравствуйте, x-code, Вы писали:
XC>Лично мне больше нравится декларативный подход в виде project файлов (при условии грамотного проектирования структуры этих файлов и возможно даже включения базовых требований к структуре в спецификацию языка программирования). А make-файлы я как не понимал, так и не понимаю (поэтому возможно, мое мнение субъективно). Интересно ваше мнение.
Здравствуйте, x-code, Вы писали:
XC>или "императивное vs деклатативное описание проектов".
XC>Исторически make-файлы появились раньше. Они связаны с интерфейсом командной строки, который был тогда единственным. По сути make-файл это скрипт на каком-то языке, который позвляет вызвать компилятор, линкер и множество других программ с любыми опциями. Организовать какую-то логику (иногда весьма нетривиальную). Все компиляторы так или иначе до сих пор поддерживают интерфейс командной строки и опции, передаваемые через него.
Make-файл — это не скрипт. Несколько упрощая, это совокупность правил, как из одних файлов получать другие. Т.е. это просто описание правил сборки.
Здравствуйте, x-code, Вы писали:
XC>или "императивное vs деклатативное описание проектов".
Я встречал другое разделение. Я не помню точную терминологию, так что введу свою; суть такова. Есть task based системы инкрементальной сборки (как MSBuild), а есть artifact based (как *make). В первой описываются зависимости (в смысле топологической сортировки) между задачами (компоновка «зависит» от компиляции, etc.), а во второй описываются описываются зависимости между входными и выходными артефактами задач (*.o-файлы зависят от *.c-файлов, *.exe-файл зависит от *.o-файлов).
Я бы не сказал, что тут есть какая-то принципиальная разница.
И то и другое — это текстовые файлы на каком-то языке (обычно очень простом).
К project file обычно прилагается какой-то более или менее монстрообразный инструмент редактирования.
Из которого произрастают все достоинства и недостатки.
Конечно, с визуальным тулзом меньше барьер вхождения.
Но зато он существенно менее гибкий.
Ну вот например я.
Нужно мне было обработать большой обьём текстов (10 Гигов) на предмет изучения сочетаемости слов.
Так вот с помощью makefile я сделал распараллеливание своей считающей программы.
Да, да, makefile умеет вызывать не только компиляторы, но и любые произвольные программы.
project file так может? Может быть и может, просто я не знаю?
Здравствуйте, x-code, Вы писали:
XC>Лично мне больше нравится декларативный подход в виде project файлов (при условии грамотного проектирования структуры этих файлов и возможно даже включения базовых требований к структуре в спецификацию языка программирования). А make-файлы я как не понимал, так и не понимаю (поэтому возможно, мое мнение субъективно). Интересно ваше мнение.
Попробуйте как-нибудь написать project file, который собирает некую тулзу из одних исходников, потом напускает ее на некие входные данные, в результате чего тулза создает другие исходники, из которых потом, вместе с третьими исходниками собирается некий результат. Причем результат должен автоматически пересобираться при изменении исходникив тулзы, ее входных данный и его собственных исходников.
Если вам это удастся, то подход в виде project файлов может и разонравиться
Здравствуйте, Pzz, Вы писали:
Pzz>Попробуйте как-нибудь написать project file, который собирает некую тулзу из одних исходников, потом напускает ее на некие входные данные, в результате чего тулза создает другие исходники, из которых потом, вместе с третьими исходниками собирается некий результат. Причем результат должен автоматически пересобираться при изменении исходникив тулзы, ее входных данный и его собственных исходников.
У меня в проектах студии такие сценарии реализуются. Правда сами проекты сгенерированны CMake'ом
Здравствуйте, Kernighan, Вы писали:
K>Я бы не сказал, что тут есть какая-то принципиальная разница.
Разница есть, смотри мой коммент выше.
K>Да, да, makefile умеет вызывать не только компиляторы, но и любые произвольные программы. K>project file так может? Может быть и может, просто я не знаю? K>:shuffle:
Начнём с того, что он не просто «project file», а скрипт MSBuild. И да, он может выполнять любые произвольные программы, и позволяет указывать зависимости между таргетами в многофазовой сборке с созданием промежуточных артефактов.
Здравствуйте, x-code, Вы писали:
XC>или "императивное vs деклатативное описание проектов".
XC>Исторически make-файлы появились раньше.
Но это не делает их недекларативными.
XC>По сути make-файл это скрипт на каком-то языке
Похоже, ты make-файлов не видел живьем.
make-файлы — это не императивный скрипт типа сначала собери то, потом се, потом вот эту команду исполни, и т.п.
make-файлы — это декларативное описание зависимостей между файлами с пристегнутым к зависимости скриптом сборки одного файла из другого.
А как и в каком порядке все это исполнять — решает сама утилита make.
Т.е. make-файл — это текстовое описание графа зависимостей (DAG), где узлы — это файлы, а к стрелочкам-зависимостям прицеплены скрипты-сборщики.
Так что, в принципие, никто тебе не мешает взять любую тулзовину для рисования графов (DOT, Rose, UML, XML) и наваять генератор мейкфайла из него (например, xslt). Это если нужно позарез именно что-то гуёвое.
Но его не составляет никаких проблем и руками писать, потому что синтаксис элементарный:
файл: зависимости через пробел
команда, чтоб собрать файл из зависимостей
Всё. Все остальное, чем наполнены мейк-файлы — это просто автоматизация при помощи переменных и т.п.
Соответственно, мейкфайл может служить абсолютно для чего угодно, когда у тебя есть пересборка файлов, которые как-то друг от друга зависят. Например, сборка файла книжки, где главы лежат отдельными файлами. Или перегенерация содержания, если что-то изменилось. Причем книжка может собираться автоматически в 18 форматах и заодно автоматом выкладываться на сайт. Или у тебя есть данные, и есть несколько прог, которые эти данные обрабатывают как-то, и есть еще куча прог, которые используют и исходные файлы, и сгенеренные. И тебе приходит апдейт одного из исходных файлов. Мейк автоматом перегенерит только то, что нужно. Причем то, что можно генерить параллельно (независимые ветки графа), он будет генерить параллельно. И т.д. и т.п.
Это не значит, что нельзя то же самое наворотить в проектных файлах (зависит от навороченности среды, которая исполняет проектный файл, но в нормальныхз средах есть возможность задать свою команду для custom build, а не только пользоваться встроенными).
Просто не недо думать, что мейкфайл ничего не способен делать и на помоечку.
ЗЫ У меня один монструозный исходник генерится ходов в 10 из кучи разных файлов, половина из которых добывается разными странными путями — xslt, grep/perl и прочая (удивительно, что еще с веба ничего не тянем). На мейкфайле все записывается очень хорошо и понятно и декларативно, за хз сколько лет ни одной проблемы не было. Если меняется один файл — перегенерится только то, что надо, не более.
Аналогично я устроил систему сборки всех сторонних библиотек. Точно так же мейкфайл отслеживает все зависимости и пересобирает только то, что надо (типа если обновился буст (или собирающий его скрипт) — не надо пересобирать питон и R, а только буст и то, что от него зависит). До того, как я сделал мейкфайл, это был ад и израиль и куча часов на пересборку всего и вся, потому что всем лень было разбираться с зависимостями вручную, проще было пересобрать все с нуля. Сейчас всем этим заведует мейкфайл, причем он сам генерится большей частью из очень маленького и компактного мейкфайла, в котором просто прописаны зависимости между библиотеками.
Makefile это гибрид. Декларативно описываются цели сборки и их зависимости. В то же время сами инструкции для сборки описываются императивно.
На мой взгляд основная проблема Makefile-ов в их плохой расширяемости и реюзабельности. Сложно скопипастить в произвольный Makefile откуда-нибудь простую строчку, чтобы в твоём проекте начались конкатенироваться и сжиматься JS-файлы. Нужно очень хорошо понимать, как это всё работает. В противовес, например, maven-у, который решает множество задач путём простой копипасты из инструкции, им пользуются куча людей, которые не особенно понимают, как он работает. Поэтому он и стал таким популярным. Никто не хочет тратить время на изучение второстепенного инструмента.
Здравствуйте, vsb, Вы писали:
vsb>Makefile это гибрид. Декларативно описываются цели сборки и их зависимости. В то же время сами инструкции для сборки описываются императивно.
Эта императивная часть просто для удобства, она не критична, она даже не часть мейк-языка, она может писаться на абсолютно любом языке — на питоне, на перле... Если бы они требовали укладываться в одну строчку и чтоб все команды были внешними — было бы лучше? Это просто способ объявить скрипт прямо внутри, не вынося его наружу в отдельный файл.
vsb>На мой взгляд основная проблема Makefile-ов в их плохой расширяемости и реюзабельности.
Расширяемости? А с ней-то что не так? Куда уж расширябельнее? правила в свободной форме, команды зови какие хочешь, они вообще не на языке мейка написаны, а на языке шелла, который ты используешь, можешь использовать хоть перл.
vsb>Сложно скопипастить в произвольный Makefile откуда-нибудь простую строчку, чтобы в твоём проекте начались конкатенироваться и сжиматься JS-файлы. Нужно очень хорошо понимать, как это всё работает.
ну мало в каком языке ты можешь взять выдрать произвольный кусок кода, воткнуть его в произвольлное место в своем коде, и чтоб все заработало. Всегда оно за собой еще что-то потянет — импорты, определения, конфигурационные переменные и т.п.
В противовес, например, maven-у, который решает множество задач путём простой копипасты из инструкции, им пользуются куча людей, которые не особенно понимают, как он работает. Поэтому он и стал таким популярным.
Ну да, Convention over Configuration в чистом виде. Все должно быть прибито гвоздями, все ходите строем с левой ноги и любите XML. Зато можно копипастить. (А в идеале — даже открывать его не надо: если все делать по стандарту, то все будет работать из коробки). В конце концов, файл мавена — это же просто файл конфига, а их обычно можно копипастить достаточно свободно. Это не свободные правила в свободном виде, как там, я не знаю, в Прологе.
vsb>Никто не хочет тратить время на изучение второстепенного инструмента.
Любой инструмент, которым ты овладел, становится нормальным инструментом, а не второстепенным — ты знаешь его сильные и слабые стороны и можешь применить с пользой для себя там, где он подходит лучше всего.
И мейк лучше всего подходит там, где надо что-то автоматом сделать с одними файлами, если изменились указанные файлы-зависимости.
Банальный пример — лог с прогоном теста зависит от тестового бинарника (или скрипта, или что ты там тестируешь) и от файлов с тестовыми данными. Если что-то из этого списка изменилось — мейк автоматом прогонит тест. (При этом тестовые данные сами тоже могут генериться из чего-нть, например, XML->CSV или CSV->binary.)
Это хороший гибкий инструмент со своей достаточно широко очерченной областью применения. А мавен — просто конфиг с одной единственной заточкой под сборку проектов.
ЗЫ Ну, то есть, я предполагаю, что на мавене тоже можно что-то серьезное кастомизированное написать, но не думаю, что в таком случае писанине будет меньше, чем с мейком. А, скорее всего, сильно больше — потому что мейк и уже очень минималистичен синтаксически.
Здравствуйте, jazzer, Вы писали:
vsb>>Makefile это гибрид. Декларативно описываются цели сборки и их зависимости. В то же время сами инструкции для сборки описываются императивно. J>Эта императивная часть просто для удобства, она не критична, она даже не часть мейк-языка, она может писаться на абсолютно любом языке — на питоне, на перле... Если бы они требовали укладываться в одну строчку и чтоб все команды были внешними — было бы лучше? Это просто способ объявить скрипт прямо внутри, не вынося его наружу в отдельный файл.
Если бы было требование укладываться в одну строчку, это был бы не make.
vsb>>На мой взгляд основная проблема Makefile-ов в их плохой расширяемости и реюзабельности. J>Расширяемости? А с ней-то что не так? Куда уж расширябельнее? правила в свободной форме, команды зови какие хочешь, они вообще не на языке мейка написаны, а на языке шелла, который ты используешь, можешь использовать хоть перл.
Плохо то, что нельзя какие то свои конструкции делать. Сложно делать обобщённые конструкции. Проводить рефакторинг, так сказать. Сложно делать свои механизмы зависимостей. Например чтобы отслеживать зависимости .c файлов от .h файлов, нужно научить компилятор выплёвывать эти зависимости в специальном формате для make-а и потом их include-ить. Это работает, но правильней было бы, чтобы make использовал какой-нибудь dependency checker в виде плагина. Вот как мне make-файл написать для Java-проекта, чтобы при изменении файла все зависящие от него файлы менялись? Скорее всего никак. Только писать скрипт-обёртку вместо javac, который будет зависимости выплёвывать аналогично gcc -M.
vsb>>Сложно скопипастить в произвольный Makefile откуда-нибудь простую строчку, чтобы в твоём проекте начались конкатенироваться и сжиматься JS-файлы. Нужно очень хорошо понимать, как это всё работает.
J>ну мало в каком языке ты можешь взять выдрать произвольный кусок кода, воткнуть его в произвольлное место в своем коде, и чтоб все заработало. Всегда оно за собой еще что-то потянет — импорты, определения, конфигурационные переменные и т.п.
J>В противовес, например, maven-у, который решает множество задач путём простой копипасты из инструкции, им пользуются куча людей, которые не особенно понимают, как он работает. Поэтому он и стал таким популярным.
J>Ну да, Convention over Configuration в чистом виде. Все должно быть прибито гвоздями, все ходите строем с левой ноги и любите XML. Зато можно копипастить. (А в идеале — даже открывать его не надо: если все делать по стандарту, то все будет работать из коробки). В конце концов, файл мавена — это же просто файл конфига, а их обычно можно копипастить достаточно свободно. Это не свободные правила в свободном виде, как там, я не знаю, в Прологе.
Вот-вот. Людям не нужна супер-гибкость. Людям надо, чтобы инструмент делал свою задачу. И им проще засунуть код в src/main/java, чем изучать The Gnu Make Manual какой-нибудь на десяток глав. Бывает, что проект вырастает, интегрируется и приходит нужна в гибкости, которой мавену не хватает. Сопровождающий проект ругается, пишет свои плагины, пишет гневные посты, но он один, а остальных много.
vsb>>Никто не хочет тратить время на изучение второстепенного инструмента.
J>Любой инструмент, которым ты овладел, становится нормальным инструментом, а не второстепенным — ты знаешь его сильные и слабые стороны и можешь применить с пользой для себя там, где он подходит лучше всего. J>И мейк лучше всего подходит там, где надо что-то автоматом сделать с одними файлами, если изменились указанные файлы-зависимости. J>Банальный пример — лог с прогоном теста зависит от тестового бинарника (или скрипта, или что ты там тестируешь) и от файлов с тестовыми данными. Если что-то из этого списка изменилось — мейк автоматом прогонит тест. (При этом тестовые данные сами тоже могут генериться из чего-нть, например, XML->CSV или CSV->binary.) J>Это хороший гибкий инструмент со своей достаточно широко очерченной областью применения. А мавен — просто конфиг с одной единственной заточкой под сборку проектов.
В современном мире знания устаревают быстро и люди очень критичны к выбору технологий, в которые стоит вкладывать своё время. Вот мне надо было сделать простой сайт, но всё же каких то ништяков хотелось вроде автоматичекой генерации css из less, минификации и прочего. Я потратил полчаса, накопипастил с разных мест скрипт для grunt-а и задачу решил. При этом я этот самый grunt особо не узнал. Но оно мне и не надо, я задачу решил. А grunt этот уже умирает, его каким-то gulp-ом заменяют нынешние девелоперы. И толку мне его изучать было?
J>ЗЫ Ну, то есть, я предполагаю, что на мавене тоже можно что-то серьезное кастомизированное написать, но не думаю, что в таком случае писанине будет меньше, чем с мейком. А, скорее всего, сильно больше — потому что мейк и уже очень минималистичен синтаксически.
Что-то совсем серьёзное обычно просто пишется на Java в виде плагина к maven-у и всё. А там делай что душе угодно.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, jazzer, Вы писали:
vsb>>>Makefile это гибрид. Декларативно описываются цели сборки и их зависимости. В то же время сами инструкции для сборки описываются императивно. J>>Эта императивная часть просто для удобства, она не критична, она даже не часть мейк-языка, она может писаться на абсолютно любом языке — на питоне, на перле... Если бы они требовали укладываться в одну строчку и чтоб все команды были внешними — было бы лучше? Это просто способ объявить скрипт прямо внутри, не вынося его наружу в отдельный файл.
vsb>Если бы было требование укладываться в одну строчку, это был бы не make.
ты как будто не прочитал остальное выше? императивная часть — не часть языка вообще. Это просто "сунь в начало строки TAB и дальше пиши, что хочешь от слова вообще — я это все скормлю той тулзе, которую ты указал". Понятно, что по умолчанию это будет какой-нть bash, но может быть что угодно, хоть Хаскель (я так думаю )
vsb>>>На мой взгляд основная проблема Makefile-ов в их плохой расширяемости и реюзабельности. J>>Расширяемости? А с ней-то что не так? Куда уж расширябельнее? правила в свободной форме, команды зови какие хочешь, они вообще не на языке мейка написаны, а на языке шелла, который ты используешь, можешь использовать хоть перл.
vsb>Плохо то, что нельзя какие то свои конструкции делать.
какие такие свои конструкции в зависимостях? Можешь пример привести?
vsb>Сложно делать обобщённые конструкции.
по паттернам, по переменным можно делать/генерить зависимости. В сложных случаях можно и скрипт какой-нть дергнуть, а его результат заинклудить просто (так выкусывание зависимостей по хедерам работает, только в роли скрипта компилятор выступает)
vsb>Проводить рефакторинг, так сказать. Сложно делать свои механизмы зависимостей. Например чтобы отслеживать зависимости .c файлов от .h файлов, нужно научить компилятор выплёвывать эти зависимости в специальном формате для make-а и потом их include-ить.
Так это не отслеживание зависимостей, а их генерация. С отслеживанием никаких проблем нет, а с генерацией — да, нужна отдельная тулза, которая умеет дополнительные зависимости выкусывать, в зависимости от типа файла — свои тулзы (я так понимаю, в мавене это называется плагинами).
vsb>Это работает, но правильней было бы, чтобы make использовал какой-нибудь dependency checker в виде плагина. Вот как мне make-файл написать для Java-проекта, чтобы при изменении файла все зависящие от него файлы менялись? Скорее всего никак. Только писать скрипт-обёртку вместо javac, который будет зависимости выплёвывать аналогично gcc -M.
Я не пишу на джаве, но, наверное, да, нечто вроде — gcc же понимает джаву, вроде как. Но в любом случае это генератор, сторонняя вещь.
Или ты имеешь в виду, что нет стандартного специального способа позвать генератор? Ну так, во-первых, он для каждого типа файла свой (а то и для отдельного файла, как в моем случае), а во-вторых, генератор тоже зовется совершенно естественным образом — через обычную зависимость самого мейкфайла от сгенеренных кусочков. Так что ничего особенного не нужно, чтоб вот именно генерацию обрабатывать.
vsb>Вот-вот. Людям не нужна супер-гибкость. Людям надо, чтобы инструмент делал свою задачу. И им проще засунуть код в src/main/java, чем изучать The Gnu Make Manual какой-нибудь на десяток глав. Бывает, что проект вырастает, интегрируется и приходит нужна в гибкости, которой мавену не хватает. Сопровождающий проект ругается, пишет свои плагины, пишет гневные посты, но он один, а остальных много.
супергибкий инструмент хорош тем, что тебе не нужно изучать десяток негибких, но заточенных.
J>>Любой инструмент, которым ты овладел, становится нормальным инструментом, а не второстепенным — ты знаешь его сильные и слабые стороны и можешь применить с пользой для себя там, где он подходит лучше всего.
vsb>В современном мире знания устаревают быстро и люди очень критичны к выбору технологий, в которые стоит вкладывать своё время.
Полностью согласен, поэтому я изучил мейк основательно один раз 20 лет назад и с тех пор горя не знаю
vsb>Вот мне надо было сделать простой сайт, но всё же каких то ништяков хотелось вроде автоматичекой генерации css из less, минификации и прочего. Я потратил полчаса, накопипастил с разных мест скрипт для grunt-а и задачу решил. При этом я этот самый grunt особо не узнал. Но оно мне и не надо, я задачу решил. А grunt этот уже умирает, его каким-то gulp-ом заменяют нынешние девелоперы. И толку мне его изучать было?
Я даже не знаю, что такое grunt Не говоря уже о gulp
Но если ты решил задачу за полчаса копипасты на абсолютно незнакомом языке — респект и уважуха.
J>>ЗЫ Ну, то есть, я предполагаю, что на мавене тоже можно что-то серьезное кастомизированное написать, но не думаю, что в таком случае писанине будет меньше, чем с мейком. А, скорее всего, сильно больше — потому что мейк и уже очень минималистичен синтаксически.
vsb>Что-то совсем серьёзное обычно просто пишется на Java в виде плагина к maven-у и всё. А там делай что душе угодно.
о ужас
Здравствуйте, jazzer, Вы писали:
vsb>>Сложно делать обобщённые конструкции. J>по паттернам, по переменным можно делать/генерить зависимости. В сложных случаях можно и скрипт какой-нть дергнуть, а его результат заинклудить просто (так выкусывание зависимостей по хедерам работает, только в роли скрипта компилятор выступает)
В makefile проблема с динамическими зависимостями. Т.е. если надо сделать какую-то обработку, сохранить в переменную и для цели вставить список зависимостей из переменной.
Для этого приходится использовать ужас под названием secondary expansion: http://make.mad-scientist.net/secondary-expansion/ или заниматься генерированием вложенных makefile'ов (путь automake). Ещё есть ужас под в виде промежуточных файлов, порождаемых цепочками wildcard-правил.
Добавим сюда ещё жуткий язык для выражений, так что задачи типа замены части имени файла становятся похожими на монстров из фильмов ужасов.
PS: на make у нас написан мегапайплайн для биоинформатики, который собирает зависимости, нарезает данные, обсчитывает их на кластере, готовит кофе, стирает бельё и вообще делает примерно 100500 других вещей.
Здравствуйте, Cyberax, Вы писали:
C>Для этого приходится использовать ужас под названием secondary expansion: http://make.mad-scientist.net/secondary-expansion/ или заниматься генерированием вложенных makefile'ов (путь automake). Ещё есть ужас под в виде промежуточных файлов, порождаемых цепочками wildcard-правил.
C>Добавим сюда ещё жуткий язык для выражений, так что задачи типа замены части имени файла становятся похожими на монстров из фильмов ужасов.
Все так. Поэтому я использую его (а secondary expansion не использую вообще) только для простых вещей, а все остальное генерю в виде подключаемых мейкфайлов (перлом, гы-гы ) либо зову $(call ...). Ну а промежуточные файлы лежат в отдельной директории для мусора (так же, как объектные файлы и прочая) и глаза не мозолят.
C>PS: на make у нас написан мегапайплайн для биоинформатики, который собирает зависимости, нарезает данные, обсчитывает их на кластере, готовит кофе, стирает бельё и вообще делает примерно 100500 других вещей.
J>Любой инструмент, которым ты овладел, становится нормальным инструментом, а не второстепенным — ты знаешь его сильные и слабые стороны и можешь применить с пользой для себя там, где он подходит лучше всего.
Во.
Золотые слова. На этом месте ветку можно было бы закрывать.
Лично моё мнение — чем проще задача, тем более простые инструменты должны быть использованы для ее решения.
