Здравствуйте, jazzer, Вы писали:

vsb>>Makefile это гибрид. Декларативно описываются цели сборки и их зависимости. В то же время сами инструкции для сборки описываются императивно.
J>Эта императивная часть просто для удобства, она не критична, она даже не часть мейк-языка, она может писаться на абсолютно любом языке — на питоне, на перле... Если бы они требовали укладываться в одну строчку и чтоб все команды были внешними — было бы лучше? Это просто способ объявить скрипт прямо внутри, не вынося его наружу в отдельный файл.

Если бы было требование укладываться в одну строчку, это был бы не make.

vsb>>На мой взгляд основная проблема Makefile-ов в их плохой расширяемости и реюзабельности.
J>Расширяемости? А с ней-то что не так? Куда уж расширябельнее? правила в свободной форме, команды зови какие хочешь, они вообще не на языке мейка написаны, а на языке шелла, который ты используешь, можешь использовать хоть перл.

Плохо то, что нельзя какие то свои конструкции делать. Сложно делать обобщённые конструкции. Проводить рефакторинг, так сказать. Сложно делать свои механизмы зависимостей. Например чтобы отслеживать зависимости .c файлов от .h файлов, нужно научить компилятор выплёвывать эти зависимости в специальном формате для make-а и потом их include-ить. Это работает, но правильней было бы, чтобы make использовал какой-нибудь dependency checker в виде плагина.

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-у и всё. А там делай что душе угодно.

Здравствуйте, 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-у и всё. А там делай что душе угодно.