GNU make 4.0

Интеграция guile (1.8/2.0+) в качестве встроенного языка расширений

Почему не Python или Lua?

Потому что GNU. Guile — официальный язык расширений GNU

Потому что лиспик педалит.

Соответственно нарушена совместимость для случая, когда переменная оканчивается на '!', будте бдительны.

Поправочка - поведение меняется в случаях, если имя переменной оканчивается на '!', а перед '=' нет пробела:

variable!= foo

Если между именем переменной и оператором присваивания есть пробел, проблем не будет:

variable! = foo

Обновился, полет нормальный

Ненужно. Есть scons и cmake (с ninja).

никогда не понимал смысла make, если его может заменить простой шелл-скрипт.

одно добавляем, другое ломаем

Шелл тяжко параллелить, насколько я понимаю.

Отчасти согласен.

Это как же? Кучей конструкций вида if ! -f $file then ... fi ? А как быть с шаблонными правилами? Переписать make на шелле несложно, но зачем? Тем более, что у make даже декларативный язык из коробки.

если его может заменить простой шелл-скрипт

Простой?!?

make и есть надстройка над shell. http://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html#Choosing-the-Shell

Нужен. Ибо cmake не сам по себе проекты собирает, а только генерирует Makefile, который потом всё равно скармливать в make.

Make - какашка и не нужен. Ninja нужен: cmake -G"Ninja".

Ибо cmake не сам по себе проекты собирает, а только генерирует Makefile, который потом всё равно скармливать в make.

Не обязательно в make, у CMake разные бекенды. Сейчас сам make скорее обуза для CMake, они используют от него минимум функционала, при этом генерируют огромное количество мейкфайлов, без которых можно обойтись.

Группирование вывода при рекурсивной параллельной сборке (--оutput-sync)

Да неужели?

уберите слово «замечательной». Для таких заявлений должны быть веские основания. Будьте нейтральны в новостях (как wiki)

Потому что не Ъ

что такое ninja ?

что такое ninja ?

Ninja — это правильный Make. С одной стороны язык Makefile недостаточно развит для систем сборки, в то же время дикий синтаксис уже непозволяет писать краткие минималистичные скрипты. В итоге единственный способ превратить Make в более-менее понятную для человека инкрементальную систему сборки можно видеть на примере Андроида — фактически изобрести новый ЯП поверх Make.

Ninja изначально позиционирует себя, по словам автора, в роли узкоспециализированного ассемблера системы сборки, код которого должен генерировать язык более высокого уровня, такой как CMake.

http://martine.github.io/ninja/

http://martine.github.io/ninja/

узкоспециализированного ассемблера системы сборки, код которого

должен генерировать язык более высокого уровня, такой как CMake

На тяжелые вещества больше смахивает. Мало того, что глючный cmake криво генерит мейкфайлы, и как что-то пошло не так, то концы не найти. А здесь еще один уровень генерации, вероятно для повышения уровня занимательности времяпрепровождения при отладке.

Cmake - это NIH же, «мы не осилили autotools, но зделаем систему лудше». Ни один приличный кроссплатформенный проект на такое не купится. Вот например OpenJDK, над ним последние пару лет работа кипит, почти полтысячи человек им занимаются сейчас. В прошлом году полностью переписали всю сборку проекта. До этого были простые мейкфайлы. А заменили их разумеется не на scons/cmake/прочую_ересь, а на autotools (которого раньше там не было). Потому что, когда надо чтобы сборка надежно работала - есть проверенные средства. А для желающих себе ноги отстреливать - да, выбор систем сборки широкий.

Вы тут про вещества упомянули, но, поправьте если ошибаюсь, тот же autotools работает по аналогичной схеме, через генерацию Makefile.

Чудесно. Надеюсь, Патрик одобрит до релиза 14.1

Что интересно, я ни разу не видел в промышленном кроссплатформенном проприетарном коде использования autotools, везде почему-то используется «scons/cmake/прочая_ересь».

Ура.

Чем Make лудше xbuild / ant ?

Ога, автотулз генерит мейкфайлы. Много лет это делает. Все возможные кривости хорошо известны. Он как maven в java - сложный, громоздкий, неидеальный, но при этом решает очень сложную проблему и делает это хорошо. Если надо что-то проще сделать, то трезвые люди выбирают подход проще. В гугле например, андроид SDK кастомные ant скрипты использует (здесь ant - это аналог make), а android NDK - убер-makefile с кучей готовых тасков, которому надо только параметры проекта скормить. И заметьте, никакой генерации.
Если нужны автотулз-лайк возможности - надо использовать автотулз. Если сборку можно проще построить - надо что-то более простое. А переписать автотулз но по своему, это либо много свободного времени + вещества, либо, как в приведенных выше проприетарных проектах, банальный job safety (привязка рабочего места к себе в смысле). Здесь чем больше ереси и уровней кодогенерации - тем лучше, пока на тебя завязана сборка флагманского продукта компании, можно не работать и продолжать получать зарплату.

А заменили их разумеется не на scons/cmake/прочую_ересь, а на autotools (которого раньше там не было).

А почему, знаешь?

Неужели потому что не осилили jam?

Так значит не знаешь?

Нет, не знаю. Судя по твоим вопросам, здесь есть какая-то скрытая причина помимо чистой и быстрой кроссплатформенной сборки?

python??? дурак чтоле? ещё этого говна в make нехватало.

от, ещё один осёл cmake с make'ом путает. LOL!

Одна беда, написано на плюсах, говно-синтаксис и всё такое. Никто не будет разбираться в сорцах и развивать проект, если аффтар на него забъёт, ибо проще всё с нуля переписать на нормальном языке. Я бы не делал бы ставку на данное решение.

Поддерживаю! К сожалению cmake не решает заявленных задач. А пляски с бубном в случае если что-то пошло не так гарантированы. Ну просто хрен поймёшь что ему не нравится. Ошибки не информативны — не хватает зависимости, а ругается совсем на другое, и подобная хрень сплошь и рядом.

К моему великому сожалению, на текущий момент autotools заменить нечем.

Что интересно, качество кроссплатформенного проприетарного кода оставляет желать лучшего (глаза б мои его не видели). А тащат scons/cmake туда вендузятники, что бы сборка под линукс в вижуалстудии работала.

Выводы делай сам.

С одной стороны язык Makefile недостаточно развит для систем сборки, в то же время дикий синтаксис уже непозволяет писать краткие минималистичные скрипты.

Это пишет человек, превозносящий cmake... Более ущербного и дикого синтаксиса, чем у cmake, я не видел. make по сравнению с cmake — конфетка.

Более ущербного и дикого синтаксиса, чем у cmake, я не видел. make по сравнению с cmake — конфетка.

Согласен, язык жуткий, зачем его изобрели для меня загадка. Для системы сборки идеально подошёл бы тот же Python с его динамической типизацией, исключениями, богатой библиотекой модулей и конструкциями языка, сильно упрощающими жизнь. В CMake даже два числа сложить или строку разобрать уже проблема. А написать функцию стаёт уделом джедаев.

Но Make тоже перехвалить сложно, возможности языка очень слабые и давно себя изжили,сейчас они явно не решают поставленных задач. Конструкции для пересборки целей спорны, отсутствует история выполнения команд, с которыми была собрана цель, ориентирование исключительно на время последнего изменения файла — этого явно недостаточно для инкрементальной сборки. Чтобы написать функцию на Make нужно сначала защитить диссертацию по написанию функций в Make, простые смертные даже заглядывать в исходный код не должны для сохранения ясности рассудка.

Сейчас учавствую в проекте, в котором система сборки на Make с завидным упорством переписывается уже в который раз. Чем посмотреть на рынок систем сборки этим людям наверное доставляет удовольствие изобретать велосипед и прыгать по граблям. В итоге последняя реинкарнация уже не содержит создание целей прямо в файле проекта, вместо неё инициализация предустановленных переменных с последующим include куска Makefile, который их понимает.

Чтобы написать функцию на Make нужно сначала защитить диссертацию по написанию функций в Make, простые смертные даже заглядывать в исходный код не должны для сохранения ясности рассудка.

Ничего подобного, там все элементарно. Главное не стесняться использовать рекурсию :3

Я вот, кстати, периодически занимаюсь тем, что написано в последнем абзаце. Сложно сказать, как то этого дошло. Рынок систем сборки забит разным говнищем, которое все равно приходится допиливать. gmake простой как угол дома, переносимый, рецепты для него напиливать проще.

Скорее всего на каком-то этапе перейду на IEEE sh + ninja

Для системы сборки идеально подошёл бы тот же Python с его динамической типизацией, исключениями, богатой библиотекой модулей и конструкциями языка, сильно упрощающими жизнь.

Python - язык общего назначения. А система сборки должна быть ограниченной и декларативной, чтобы можно было генерить код проектов любой возможной IDE. Ничего «вычислимого» в системе сборки не должно быть вовсе.

В CMake даже два числа сложить или строку разобрать уже проблема.

Руки отрывать за такое.

Вот открыл наугад из Андроида:

define find-parent-file
$(strip \
  $(eval _fpf := $(wildcard $(foreach f, $(2), $(strip $(1))/$(f)))) \
  $(if $(_fpf),$(_fpf), \
       $(if $(filter-out ./ .,$(1)), \
             $(call find-parent-file,$(patsubst %/,%,$(dir $(1))),$(2)) \
        ) \
   ) \
)
endef

Я серьёзно пытался раз разобраться где проблема в моей сборке через вереницу подобных вызовов. Всё это усугубляется тем, что Мейкфайлы не стесняются включать друг друга, суммируя переменные и функции в один большой глобальный список. В итоге элементарно забыть объявить переменную, а неочищенная переменная ведёт вообще к непредсказуемым результатам совершенно в другом месте.

А вот и школоло понабежало.

Расскажи, тупое школоло, почему в LLVM переходят на CMake с autotools?

А система сборки должна быть ограниченной и декларативной

На счёт декларативности можно поспорить, к примеру тот же CMake полностью императивный, что не мешает ему выполнять свои задачи. Но я с интересом наблюдаю и за идеей QBS, в основе которого QML как декларативный язык с возможностью императивщины на JS.

Android NDK - куча говна. Они слишком злоупотребляют eval'ом и портят стандартный механизм наполнения переменных. Скорее всего чуваки которые её напиливали, видели gmake в первый раз.

Для своих костылепроектов я перешел на собственный вариант билда под андроид, используя тулчейны NDK напрямую.

Конкретно эта функция рекрурсивно отпиливает куски пути и проверяет наличие файлов в получившемся каталоге вайлдкардом. Мне кажется, вполне прозрачно написано, хотя лучше бы в пару разложить :D

каких интересно задачь не решает cmake? звучит так что вы просто не понимаете о чем говорите. давно уже пользуюсь cmake и он прекрасен. кросс-сборки, сборка под VC (под mingw сложные проекты собирать моветон - половина новых API не доступна, тот-же Google Chrome собирается через VC компиляторы), поддержка кучи тулзов «из каропки» (Qt, Doxygen и так далее), драйвер юнит тестов (умеет даже их паралелить аля ctest -j5), пекейджер (разные zip'ы и прочие инсталяторы генерить с минимум усилий). ничего этого нет в autotools. плюс autotools + make безбожно тормозят по сравнению c cmake + ninja (на винде в тройне безбожно тормозят, вот только в gmake 4.0 наконец сделали сервер паралелизации, раньше его тупо небыло, т.е. -j3 не работал, только неограниченный -j). кросс-сборка или канадский-крест с autotools кстати говоря еще тот цирк, _постоянно_ вылезают проблемы, без патчей и хаков даже не лезь, а configure.ac для поддержки таких компиляций монстрятина еще та (видимо поэтому и ломаются постоянно в gcc). в cmake кросс-компиляция не идеальна но не настолько ущербна как в auto-tools имхо, она тупо надежней и проще за счет import/export таргетов между стейджами.

под mingw сложные проекты собирать моветон

Немного оффтопом, есть соображения, отчего так сложилось? MSVC использовать в кроссплатформенной сборке - это очень больно (астрологи объявили месяц cygwin'а, количество проблем и время сборки выросли по экспоненте). MinGW64 же требует минимального допиливания сборки (если код винду поддерживает). С99 опять же там есть. Скорость бинарников из MinGW сранима с MSVC и даже выше. При этом все большие проекты под винду (python, postgres и т.д.) используют MSVC. MinGW недостаточно стабильный вероятно? Я в нем никогда с проблемами не сталкивался, но и ничего серьезного не собирал на нем.

Да, возможно за этим будущее. Однако в огромном множестве проектов используется Make, по крайней мере как бэкэнд. И чтобы заменить его уйдёт уйма времени. Вот ещё одна попытка сделать Make правильным http://gittup.org/tup/make_vs_tup.html